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Human-Centered  Shipboard  Systems 
and  Operations 


20.1  BACKGROUND 

One  of  the  primary  principles  of  successful  human  systems  integration  (HSI)  in  systems 
engineering  and  management  is  utilizing  a  human-centered  design  (HCD)  approach 
throughout  the  systems  acquisition  process  (Chapters  1,  10,  and  18).  Several  other 
chapters  (Chapters  4,  6,  7,  and  9,  in  particular)  have  pointed  out  the  need  to  establish 
HSI  requirements  early  in  the  process,  if  the  HCD  principle  is  to  be  folly  effective. 
Unfortunately,  system  design  requirements  based  upon  human  capabilities  and  limitations 
may  not  be  considered  early  in  the  design  process,  leading  to  costly  changes  during 
implementation.  Often,  new  systems  simply  evolve  from  past  systems  approaches  using 
established  procedural  and  design  methods. 

The  designer  may  rely  on  the  user  during  the  requirements  stage  to  consider  the  human 
component,  but  user  input  must  be  carefully  considered  in  that  it  can  maintain  previous 
designer  flaws  relative  to  human  performance.  User  input  and  design  qualities  must  be 
abstracted  into  basic  task  requirements.  Unless  the  methods  and  procedures  used  in 
establishing  requirements  are  specifically  analyzed  for  impact  on  human  performance  and 
efficiency,  neither  the  user  or  the  designer  is  likely  to  folly  recognize  the  effect  the  design 
will  have  on  the  human  component  when  the  system  is  fielded. 

A  major  requirement  for  improved  user  interface  and  decision  support  aboard  ships  has 
arisen  from  the  need  for  crew  size  optimization.  Optimization  must  be  achieved  without 
sacrifice  of  performance,  mission  risk,  and  without  crew  overload.  Crew  optimization  in 
future  ships  has  been  recognized  as  a  significant  cost  factor  and  therefore  has  become  a 
performance  capability  objective  for  newer  classes  of  ships  [Naval  Sea  Systems  Command 
(NAVSEA),  1996,  1997].  When  the  U.S.  Navy  required  a  drastic  reduction  of  crew  size 
from  350  to  95  personnel  on  DD  21  ships,  it  recognized  the  need  to  use  HSI  principles  for 
equipment  design  requirements  and  design  solutions  to  successfully  achieve  mission 
objectives  (Bush  et.  al.,  1999). 
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Consequently  the  Multimodal  Watchstation  (MMWS)  project  was  conceived  as  a 
risk-reduction  research  effort  to  create  concept  designs  that  aid  in  HSI  with  optimized 
crews.1  The  concept  designs  also  demonstrated  a  task-centered  approach  to  requirements 
determination  during  the  system  definition  stage,  without  major  restrictions  imposed  by 
current  design  practice. 

20.1.1  Multimodal  Watchstation  Project 

As  an  example  of  the  early  stages  of  the  design  process  and  its  products,  MMWS 
represents  the  conceptual  design  stages  of  engineering,  before  full-scale  development  is 
attempted.  The  purpose  of  concept  definition  is  not  to  create  a  product  for  final  delivery  or 
fielding  but  to  investigate  innovative  features  that  are  hypothesized  to  improve  human 
performance  and  training.  This  process  further  refines  requirements  and  guidelines  that  are 
then  transferred  into  advanced  engineering  model  development.  The  reader  must  recog¬ 
nize,  however,  that  the  primary  MMWS  project  focus  is  on  software-based  decision  aids 
and  not  on  watchstation  hardware  or  display  technology.  The  hardware  design  is  totally 
driven  by  available  commercial  display  and  control  technologies,  with  some  innovation  in 
how  the  technologies  are  integrated  and  used  by  the  software,  together  with  ergonomic 
features  for  the  physical  configuration.  As  display  technologies  improved  over  the  project 
life,  the  watchstation  was  also  modified  to  take  advantage  of  these  changes.  The  primaiy 
focus  of  the  MMWS  design  project  was  simulation-based  design,  in  which  a  user  interface 
simulation  was  constructed  to  test  and  refine  requirements. 

The  conceptual  design  process  included  the  identification  of  critical  tasks  within  one  of 
the  two  broad  mission  domains  and  the  specification  of  task  requirements  based  on  task 
characteristics  and  job  design.  This  evolutionary  approach  allowed  for  technology 
insertion  and  improvements  over  the  4-year  MMWS  concept  design  cycle,  with  operator, 
involvement  in  all  stages  of  the  design  process. 

Over  the  4-years  to  complete  the  project,  requirements  were  generated  using  a 
task-centered  design  approach  from  which  alternative  design  concepts  were  developed. 
The  design  concepts  were  subjected  to  a  series  of  usability  tests  and  team  performance 
evaluations  to  verify  that  both  human  performance  and  training  objectives  could  be  met. 
Performance  and  workload  measures  were  collected  with  reduced  crews  relative  to  today’s 
systems  estimating  the  potential  impact  on  crew  size  optimization. 

The  iterative  design  process  resulted  in  a  mission  execution  and  management  system 
prototype  capable  of  simulating  work  activity  typical  of  navy  command  and  control 
information  centers  and  designed  for  meeting  mission  goals  for  both  land  attack  and  air 
defense  operations.  The  warfighting  functions  supported  by  the  MMWS  are  the  same  as 
current  command  and  control  centers  but  offer  reduced  workload  and  workload  distribu¬ 
tion  capabilities  among  team  members  that  may  enable  crew  size  optimization. 

The  work  discussed  in  this  chapter  applies  directly  to  the  ship  command  center 
information  systems  design  and  does  not  imply  that  crew  size  is  reduced  for  other  ship 
operational  functions  as  a  result.  Decision  support  systems,  cooperative  automation,  and 
effective  displays  are  enablers  of  optimized  crews  but  do  not  directly  reduce  crew  size, 
unless  other  operational  methods  are  changed. 

The  path  from  requirements  to  effective  display  and  interface  design  is  multidimen¬ 
sional.  If  requirements  omit  major  work  factors  that  contribute  workload  or  performance 
risk,  the  resulting  design  solution  is  at  risk.  There  is  a  degree  of  art  and  innovation  in 
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|fp  design  not  easily  quantified,  and  it  is  likely  that  multiple  design  solutions  can  work  to 
Ig  achieve  acceptable  performance  as  well.  Despite  this  first  impression  that  one  design 
example  and  set  of  requirements  only  serve  as  a  loose  connection  with  other  designs,  we 
!f|f§  are  seeing  a  broader  use  of  decision  support  “components”  that  are  modified  across 
§|f  diverse  mission  areas,  without  the  need  to  “reinvent  the  wheel”  for  new  task  requirements. 
..  The  specific  design  properties  that  address  the  task-centered  requirements  identified  in  the 
i  £?.'  -  MMWS  project  also  apply  to  other  mission  areas  and  work  settings  such  as  ship 
propulsion  and  engineering  tasks  (Osga,  2001). 

®! |  Thus,  an  important  lesson  learned  to  retain  throughout  the  chapter  discussion  is  that  the 
!  k  type  of  requirements  and  type  of  tasks  covered  are  stable  within  the  task-centered  approach 
across  diverse  systems.  This  stability  allows  for  modification  of  various  design  compo- 
’ ' '  nents  to  “fine-tune”  results  for  various  missions,  such  as  defensive,  strike  warfare,  and  ship 
engineering  control.  In  all  cases,  the  human  has  a  need  to  project  mission  events  ahead  in 
I  time  in  order  to  visualize  the  upcoming  processes  and  anticipate  potential  results.  It  is  then 
I  possible  to  enact  mission  solutions  based  on  lower  stress  planned  responses  rather  than  on 
!  fy  surprised  and  late  reactions  to  failures. 

jjiy  The  advantage  of  HSI  research  and  development  in  the  early  conceptual  process  is  that 
design  ideas  of  varying  risk  can  be  combined  and  tested,  with  the  ability  to  accept  or  reject 
design  solutions  based  on  iterative  modeling  or  human  performance  testing.  This  design 
process  will  vary  between  every  project  based  on  the  cost  and  expertise  of  the  design  team, 
j  Important  qualities  of  the  MMWS  decision  aids  were  defined  through  years  of  focused 
research  related  to  the  air  defense  task  domain.  The  project  allowed  the  integration  of 
,  various  design  concepts  and  techniques  in  a  common  design  approach.  Important 

j  innovations  were  newly  derived,  however,  based  on  task  support  areas  not  previously 

addressed. 


20.1.2  Chapter  Overview 

This  chapter  presents  a  conceptual  design  process  based  on  the  experience  with  the 
MMWS  project.  A  significant  part  of  this  process  lies  in  the  definition  of  tasks  and 
i  establishment  of  key  requirements.  An  HCD  focus  characterizes  tasks  in  an  information 
system  work  space  according  to  task  qualities  and  dynamic  properties.  This  task-centered 
approach  drives  design  thinking  toward  solving  users’  needs  across  a  broader  spectrum  of 
i  task  types  and  dynamics  than  is  typically  considered  by  systems  designers, 
i  The  chapter  is  divided  into  the  following  sections  that  describe  how  HSI  requirements 
were  defined  and  design  solutions  for  these  requirements  were  addressed  in  the  MMWS 
project: 

i  •  Task-centered  approach 

f.  *  Task  coverage  requirements 

’  Human  support  task  requirements 
!:  '  Dynamic  task  requirements 

•  Design  by  task  requirement 

’  Other  design  qualities 
.  *  Benefits  of  task-centered  design 
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20.2  TASK-CENTERED  APPROACH 

The  task-centered  approach  fits  into  a  conceptual  design  process,  as  shown  in  Figure  20  1 
The  process  is  iterative  and  cyclic,  meaning  that  not  all  system  design  components  and 
features  are  fully  developed  at  the  same  time  and  fully  output  to  another  design  processing 
stage.  ° 

First,  mission  and  task  requirements  are  derived  from  design  reference  missions 
(DRMs),  which  capture  the  future  use  of  the  system  into  a  time-based  story  depicting 
system  use.  The  quality  of  the  DRMs  is  critical  for  system  requirements  and  definition  of 
scope. 

Mission  tasks  are  then  derived  as  part  of  an  iterative  function  allocation  process,  with 
levels  of  desired  automation  considered  for  each  task.  The  function  allocation  may  not  be 
entirely  fixed  in  a  dynamic  system  in  which  the  user  can  vary  function  allocation.  This 
phase  of  processing  produces  the  DRM,  task  definitions,  task  flows,  and  decision  points  to 
describe  the  task  domain. 

The  human-computer  interface  (HCI)  design  is  developed  and  validated,  as  shown  in 
the  lower  right  circle  in  Figure  20. 1 ,  with  input  from  related  discovery  research  and  other 
decision  support  tools  that  may  be  modified  to  fit  the  current  mission  focus.  Important 
design  requirements  (beyond  just  the  mission  task  requirements)  that  feed  this  part  of  the 
design  process  are  discussed  later  in  the  chapter. 

The  software  validation  process  and  prototyping  are  conducted  to  verify  that  computa¬ 
tional  methods  can  be  found  that  are  reliable,  accurate,  and  serve  the  information  needs  of 
the  tasks.  This  prototyping  process  can  be  separate  from  the  HCI  prototyping  and 
requirements  definition  thus  enabling  HCI  designers  and  software  engineers  to  coordinate 
work  in  a  parallel  process.  The  HCI  prototypes,  whether  in  paper,  slide  show,  or  simulation 
may  be  subject  to  repeated  usability  tests  before  they  are  submitted  to  the  software 
prototyping  process.  As  usability  data  is  collected  and  HCI  requirements  mature  and  are 
better  specified  over  time,  they  serve  as  input  to  the  software  validation  process. 

An  important  facet  of  this  approach  is  that  in  large  complex  systems,  requirements  and 
design  are  not  fully  described  as  in  a  hierarchical  noniterative  approach  but  that  testing  and 
refinement  can  occur  over  time  for  “pieces”  of  the  system.  The  software  architecture  is 
also  designed  to  accommodate  successive  improvements  over  time.  The  chapter  content 
primarily  covers  the  “task  analysis”  and  “HCI  design  and  validate”  parts  of  this  design 
process. 

Before  proceeding  further  into  the  design  process  example  with  MMWS,  several 
important  terms  used  throughout  the  chapter  should  be  defined.  Several  basic  definitions 
related  to  “tasks”  are  needed  to  better  understand  the  task-centered,  approach  as  a  design 
process.  These  are  task,  mission  task,  task  description,  job  design,  and  task  definition, 

A  task  is  a  goal-oriented  work  activity  component  of  a  job.  The  task  may  be 
accomplished  manually,  automatically,  or  some  combination  of  the  two.  The 
composite  of  all  tasks  for  a  given  job  description  accounts  for  all  workload  during 
a  prescribed  work  period. 

Mission  tasks  are  workload  producing  components  typically  addressed  in  military 
system  specifications  involving  human  control  elements. 

A  task  description  represents  a  taxonomic  description  of  labeled  work  activities,  This 
creates  a  written  description  of  a  definable  process  by  which  human  and  machine 
cooperate  at  achieving  a  work-related  goal. 
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A  job  design  is  a  collection  of  tasks  defined  as  a  set  of  related  work  goals  to  which  a 
human  operator  is  assigned  to  complete. 

Task  definition  is  the  process  of  putting  defined  labels  on  a  set  of  work  activities.  There 
is  no  unified,  agreed  approach  within  the  human-engineering  discipline  on  task 
labels.  Typically  it  is  up  to  the  system  designer  and  architect  to  define  a  hierarchy 
and  level  of  detail  judged  appropriate  for  the  design  problem. 

The  task-centered  approach  is  an  analytical  HSI  design  process  broadly  comprising  two 
components: 

•  Defining  HSI  requirements  within  defined  task  domains 

•  Creating  task-centered  designs  supporting  task  goal  achievement 

Defining  HSI  requirements  is  the  focus  of  the  remainder  of  this  section  and  Sections  20.3, 
20.4,  and  20.5.  Creating  task-centered  designs  is  the  focus  of  Sections  20.6  and  20.7, 


20.2.1  Establishing  Key  HSI  Requirements 

The  premise  is  that  a  task-centered  design  focus  during  the  systems  engineering  process 
provides  a  mechanism  to  fully  describe  the  work  environment  in  a  manner  that  establishes 
a  comprehensive  set  of  design  requirements.  These  requirements  are  structured  to  cover  the 
various  types  of  tasks  that  compose  the  majority  of  workload  sources  at  the  tactical 
watchstation.  Another  important  premise  is  that  design  attention  must  be  paid  to  the  major 
sources  of  workload  whether  they  be  mission,  computer-interface,  human  information 
processing,  or  work  management  tasks.  These  tasks  also  operate  in  a  dynamic  work  cycle 
with  defined  phases.  Much  of  today’s  design  focus  in  legacy  ship  systems  is  on  a  narrow 
subset  of  processes  within  the  task  work  cycle,  leaving  the  system  operators  unsupported 
to  use  their  visual  and  cognitive  resources  to  carry  the  workload  through  the  unsupported 
task  phases. 

A  process  that  is  key  to  successful  HSI  is  adequate  description  of  the  system  task  and 
work  environment.  A  design  concept  is  simply  a  set  of  design  hypotheses  matching  design 
solutions  to  the  task  requirements,  with  the  hypotheses  being  made  relative  to  the  human 
performance  outcome  in  both  training  and  operational  results.  A  task-centered  approach 
can  be  used  to  directly  tie  requirements  to  task  characteristics. 

The  most  important  concepts  utilized  in  establishing  key  HSI  requirements  are: 

1.  Task  Coverage  The  quantity  of  tasks  and  the  qualities  of  task  requirements 

addressed  by  the  designer  relative  to  the  entire  workload  environment  within  the  job 
design.  A  major  concern  here  is  the  breadth  of  the  tasks  in  job  design.  If  a  task  is  not  even 
considered  or  recognized  by  the  designer,  then  there  can  be  no  hypothesized  design 
solution.  Most  of  the  major  types  of  tasks  (e.g.,  mission,  computer,  work  management,  and 
human  support  tasks,  along  with  the  various  types  of  support  requirements  for  situation 
awareness,  attention  management,  and  decision  making)  can  be  developed  through  the 
method  of  task  definition.  These  types  of  requirements  can  be  thought  of  as  “static”  task 
requirements,  in  the  sense  that  task  qualities  can  be  described  independent  of  time  or 
sequence.  ■  A 

2.  Task  Dynamics  The  life  cycle  of  a  task  within  a  dynamic  task  decision  process. 
The  dynamic  properties  of  tasks  are  described  with  reference  to  how  these  dynamic 
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properties  Create  additional  design  requirements.  For  example,  human  memory  is  subject 
to  decay  over  time.  Task  interruptions  are  affected  by  time.  Task  deadlines  and  parallel 
tasks  affect  workload.  The  dynamic  pacing  and  workload  requirements  of  the  job 
environment  are  not  readily  visible  when  each  task  is  analyzed  independently  and  out 
of  the  timing  context. 

3.  Task  Goals  The  detailed  level  focus  of  system  design  needed  to  create  the  task 
product  in  an  efficient  and  cost-effective  manner. 

Task  coverage  and  task  dynamics  will  be  covered  in  more  detail  in  the  following  sections, 
but  since  the  process  of  establishing  key  HSI  requirements  starts  with  task  goals,  they  are 
described  in  the  following  section. 


20.2.2  Definition  of  Task  Goals 

The  goal  of  many  mission  tasks  is  to  create  a  product  (e.g.,  an  order,  control  action, 
message,  awareness  update),  but  a  task-centered  design  goal  is  often  a  process.  For 
example,  to  reduce  human  cognitive  workload,  the  task  goal  may  be  to  move  tasks 
from  requiring  knowledge-based  aptitudes  toward  the  skill  or  rule-based  performance 
(Rasmussen,  1986).  For  such  tasks  the  goal  would  be  to  relieve  the  user  of  tedious  rule-  or 
skill-based  steps,  by  capturing  such  processes  within  algorithms  or  computational 
resources  that  result  in  the  presentation  of  “draft”  task  products  for  human  verification 
and  delivery.  Thus,  as  designers  we  shift  the  human  role  in  system  interaction  from 
repetitious  lower  level  task  rules  toward  a  role  of  monitoring  and  directing  automated 
processes  that  produce  “draft”  products  for  human  inspection. 

The  purpose  of  a  task  in  the  context  of  human  work  is  for  the  useful  completion  of  work 
related  to  mission  goals.  The  definition  of  task  goals  is  critical  in  early  design  stages  in  that 
they  describe  any  gaps  between  the  conceptualized  system  products  and  the  task  goals  that 
the  human  must  support.  As  we  see  in  the  task  definition  process  described  in  the  next 
section,  the  scope  of  these  goals  may  be  broad  or  narrow  depending  on  the  vision  of  the 
designer  and  the  acknowledgment  of  the  types  of  tasks  and  their  associated  goals. 

Goals  can  usually  be  stated  in  hierarchical  terms,  and  the  designer  must  make  important 
design  decisions  as  to  what  type  of  functional  system  support  to  provide  toward  the 
attainment  of  task  goals  at  various  hierarchical  levels.  See  Example  20.1. 

Example  20.1  Message  Preparation  Requirements  The  task  of  message  preparation  and 
delivery  to  meet  a  mission  requirement  may  be  supported  across  various  subtask  steps  of 
information  collection,  message  creation,  editing,  formatting,  and  delivery.  A  word  processor 
may  support  the  functional  goal  of  writing  text  in  the  message  format  with  various  features  to 
support  text  editing.  Consistency  across  messages  may  be  supported  by  display  views  that 
show  proper  message  format.  The  system  could  collect  the  proper  information  for  the  message 
and  prepare  a  draft  message  if  the  form  and  content  is  known.  The  same  function  can  be 
supported  with  only  a  basic  word  processor,  forcing  the  user  to  collect  information  and  type  in 
the  message  based  on  training  and  task  expertise.  With  minimum  support,  the  user  must 
collect  the  information  from  displays,  form  the  message  content  in  their  head,  and  verbally 
speak  the  message  to  the  receiver  while  perhaps  writing  notes  with  no  system  support  for 
creation,  editing,  and  delivery.  In  each  example,  the  task  goal  remains  the  same  for  the  user — 
deliver  a  correct,  timely,  and  succinct  message  as  soon  as  it  is  required — but  the  requirements 
for  system  support  would  vary  tremendously  depending  on  how  much  automation  and  task 
product  drafting  the  system  is  required  to  support  the  user.  Task-centered  design  attempts  to 
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identify  requirements  related  to  task  goals  and  provide  support  through  all  task  phases  leading 
to  the  goal  accomplishment. 

Many  task  performance  goals  could  be  derived  from  mission  performance  require¬ 
ments.  If  the  requirement  is  set  at  five  messages  per  minute  or  no  more  than  5  percent  error 
in  message  content,  the  contractor  and  designer  must  determine  a  human-system  solution 
that  meets  performance  goals.  Without  the  specification  of  performance  goals,  design 
becomes  a  somewhat  arbitrary  process  of  debate  between  the  human  factors  engineer  and 
project  management  on  what  level  of  system  support  is  proper  or  needed.  Unfortunately, 
the  definition  of  performance  requirements  and  design  solutions  often  does  not  involve  the 
human  component.  When  focused  correctly  technology  support  could  often  provide 
improved  performance  with  improved  HSI,  resulting  in  more  accurate  adjustment  of 
task  performance  goals  and  mission  requirements  based  on  those  improvements. 

The  research  process  should  play  an  important  role  in  the  setting  of  task  goals.  In  an 
impartial  lab  setting,  task  goals  are  not  artificially  held  back  or  restricted  by  business 
practices,  risk  aversion,  or  loyalty  to  a  specific  product  or  approach.  Research  must 
identify  tasks  and  goals  representative  of  operational  requirements.  Results  should  provide 
“honest  broker”  evaluation  of  a  system’s  qualities  and  its  potential  to  support  task  goals. 
Setting  of  task  goals  represents  common  metrics  of  quality  across  disparate  design 
approaches,  and  as  such,  the  goals  create  the  opportunity  to  specify  performance 
objectives  as  metrics  of  system  success. 

Task  goals  provide  a  focus  for  design  of  task  products,  and  task  coverage  defines  the 
breadth  of  design  support  toward  the  attainment  of  the  variety  of  task  goals.  Sections  20.3, 
20.4,  and  20.5  describe  how  HSI  task  coverage  and  task  dynamic  requirements  were 
developed  for  the  MMWS  in  support  of  various  task  goals. 


20-3  TASK  COVERAGE  REQUIREMENTS 

Task  coverage  represents  the  amount  of  work  activity  that  the  designer  supports  with 
system  features.  In  the  MMWS  project,  task  coverage  represented  a  comprehensive  view 
of  the  work  requirements  for  an  air  defense  mission  application,  and  a  “task  to  be  covered” 
was  defined  as  a  segment  of  a  job  activity  with  the  following  attributes: 

•  Varying  in  time  from  seconds  to  hours,  or  the  entire  watch  period  (6  hours  or  more). 

•  Supportable  by  computer-based  aids,  (e.g.,  not  work  activities  such  as  physically 
connecting  cables  or  cleaning  and  maintenance). 

•  Supportable  by  various  levels  of  automation,  which  may  include  user  selectable  or 
fixed  automation  levels.  Thus,  levels  of  task  supervision  and  user-system  task  sharing 
are  dynamic. 

•  May  vary  from  structured,  rigid  protocols  .to  open-ended  user-defined  sequences. 
Following  Rasmussen’s  (1986)  hierarchy,  tasks  may  include  skill-,  rule-,  or 
knowledge-based  behaviors.  Many  tasks  in  the  air  defense  warfare  area  had  defined 
procedures  and  structured  protocols  and  could  be  defined  as  rule-based  tasks. 

Task  coverage  is  strongly  influenced  by  designer  vision,  cost,  and  time.  Often  the 
potential  system  support  is  a  result  of  design  vision  to  see  how  potential  technology, 
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algorithms,  and  computational  methods  can  be  utilized  in  support  of  tasks.  During  early 
design  concept  formulation,  user  task  activities  must  be  discussed  and  judgments  rendered 
as  to  whether  the  activity  is  “too  difficult”  or  “too  costly”  to  support.  Revised  design 
vision  might  appear  weeks  or  months  later  during  the  task  definition  and  analysis  process. 
The  level  of  task  support  may  be  increased  with  upgraded  versions  of  the  software  and 
system.  These  successive  improvements  create  a  requirement  for  a  flexible  software 
architecture  to  allow  for  expanded  user  support  while  task  requirements  evolve.  Thus, 
during  the  early  stages  in  the  conceptual  design  process,  it  is  imperative  to  identify  as 
complete  a  concept  of  task  coverage  as  possible,  while  avoiding  premature  narrowing  of 
design  focus  because  an  immediate  solution  is  not  readily  available. 

A  significant  step  in  the  task  coverage  analysis  process  is  to  identify  all  the  critical  task 
goals  in  the  job  domain.  Task  definitions  are  strongly  related  to  task  goals.  These  goals  are 
a  starting  point  from  which  to  create  task  definitions.  For  example,  the  goal  to  create  and 
send  a  new  track  report  message  in  MMWS  is  covered  under  the  task  with  the  same  name 
“create  new  track  report.”  Other  goals  such  as  “review  rules  of  engagement”  have  the  goal 
of  updating  short-term  memory  during  the  mission  progression  with  information  that 
affects  other  task  decisions.  Thus,  task  goals  may  be  to  produce  defined  products  such  as  a 
mission  order,  mission  report,  message,  plan,  etc.,  or  the  goal  may  be  to  update  and 
reinforce  information  storage  supporting  situation  awareness  in  the  human  cognitive 
processor. 

Subject  experts  are  able  to  define  concrete  task  products  relatively  easily  but  appear  to 
have  much  more  difficulty  with  goals  that  are  related  to  cognitive  processing.  This  process 
can  be  aided  by  task  walkthroughs  or  observations  of  task  progress  with  experts  used  to 
explain  these  processes.  The  task  definition  process  must  be  as  thorough  as  possible  to 
ensure  that  complete  coverage  is  considered,  and  the  level  of  functional  support  within  the 
coverage  area  is  based  on  deliberate  design  decisions  on  how  much  workload  to  allocate  to 
human  or  machine  to  cooperatively  achieve  the  goals. 

For  MMWS  design  purposes  five  main  classes  of  tasks  were  defined  as  requiring 
support  by  the  watchstation  design.  These  classes  were: 

1 .  Mission  tasks 

2.  Human  support  tasks 

3.  Work  space  computer  management  and  control  tasks 

4.  Work  management  tasks 

5.  Communication  tasks 

These  classes  represent  a  total  task  coverage  approach  to  the  MMWS  workload.  Within 
each  of  the  classes  of  tasks,  the  process  of  task  definition  was  applied  to  create  task  labels 
that  made  sense  to  both  designer  and  subject  expert,  and  were  explainable  and  defendable 
to  software  engineers  and  project  management. 

20.3.1  Task  Definition  Process 

The  process  of  task  definition  may  differ  significantly  if  the  system  design  problem  is  an 
upgrade  to  an  existing  task  process  or  if  the  system  is  a  new  or  innovative  concept.  With 
system  upgrades  there  may  be  increased  pressure  from  current  users  and  management  to 
minimize  impact  on  training  or  documentation  costs:  With  a  new  system  there  is  less 
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legacy  and  design  tradition  to  affect  the  task  definitions.  Designers  must  analyze  the 
current  task  process  carefully  and  define  task  elements  at  different  levels.  The  designer 
must  look  for  inefficient  or  awkward  methods  in  current  procedures.  These  factors  affect 
the  manner  in  which  the  task  taxonomy  is  described  and  then  formulated  for  the  new 
system. 

Subject  matter  experts  (SMEs)  will  most  likely  describe  their  tasks  within  the  scope  of 
the  current  work  environment.  Some  air  defense  warfare  tasks  were  initially  omitted  in 
MMWS  because  the  current  design  provided  little  or  no  support  for  those  tasks;  therefore 
they  were  not  part  of  the  software  description  or  documentation.  Without  some  introspec¬ 
tion  and  observation  of  current  task  processes  in  action,  these  undocumented  tasks  remain 
invisible  to  the  designer.  Also,  the  goal  of  a  task  can  be  obscured  by  lack  of  foil 
documentation  of  the  current  systems’  task  process.  For  example,  the  SME  might  guide  the 
task  definition  and  process  for  a  communications  task  toward  designing  refinements  to 
support  that  process,  hence  focusing  the  design  discussion  on  improving  today’s  process. 
With  tasks  related  to  voice  communications,  the  SME  drove  the  design  discussion  toward 
better  communication  methods  or  technologies.  Further  analysis  on  the  task  product 
changed  the  task  definition  by  revealing  a  potential  improvement  in  performance  by 
focusing  on  the  preparation  and  delivery  of  the  tasks’  communication  products. 


Example  20.2  Human  Factors  and  Computer  Science  Collaboration  During  Task 
Definition  The  MMWS  design  hypothesized  that  perhaps  a  voice  message  can  be  prepared 
automatically  and  sent  digitally  without  requiring  the  human  to  both  conceive  and  verbalize 
the  report  through  a  communication  channel.  The  human  factors  engineer  estimated  a 
reduction  in  workload  if  this  technology  can  be  implemented  while  the  computer  scientist 
determined  if  there  was  sufficient  task  structure  to  automate  the  message  preparation.  When 
the  task  requirements  are  stated  first,  it  allows  greater  flexibility  in  the  design  discussion  than 
if  the  design  solution  is  discussed  first. 


A  key  lesson  learned  during  the  MMWS  project  was  to  define  task  “products  first  or 
early  in  the  task  definition  stage.  If  a  product  cannot  be  clearly  defined,  the  task  concept 
may  be  a  candidate  for  being  “reduced”  to  a  task  “step”  or  “subtask”  within  another 
defined  task  area. 

With  system  design  changes,  tasks  may  become  obsolete  or  technology  can  change  the 
entire  nature  of  the  task  or  process.  Tasks  may  evolve  from  totally  manual  to  partially 
automated  to  produce  “intermediate”  products  in  a  multistage  complex  process.  Other 
tasks  have  easily  defined  beginning  and  end  points  and  concise  products.  There  are  no 
clearly  defined  quantitative  solutions  to  defining  the  best  “size”  and  workload  of  the  work 
activity  within  a  given  task  label.  The  function  of  “job  design”  is  to  subgroup  tasks  an 
work  in  a  manner  that  allows  user  work  pacing  and  rest  in  manageable  cycles.  Typical  y, 
the  more  concise  and  smaller  the  task  with  respect  to  time,  complexity,  and  steps,  the  less 
likely  the  task  will  be  interrupted,  left  incomplete,  or  subject  to  forgetting.  Fewer  tas  s 
relate  to  a  more  manageable  design  problem,  software  effort,  and  user  training  e  o  • 
Smaller  tasks  with  simple  procedural  steps  produce  easier  training  challenges  that  may  e 
presented  in  a  building-block  fashion.  The  ability  to  combine  smaller  task  products  into 
larger  outcomes  also  facilitates  training  and  instruction.  Guidelines  for  the  purpose  o 
defining  task  size  and  complexity  in  MMWS  include  the  definition  of  a  task  unit  that  is 
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A  “trainable  unit”  (e.g.,  a  cohesive  and  related  set  of  goals) 

A  reasonable  software  design/build  module  (e.g.,  a  related  set  of  computations  and 
results) 

A  reasonable  grouping  of  information  and  goals  (e.g.,  related  information  and  logical 
process  flow) 


The  task  definition  process  may  generate  confusion  about  how  to  define  the  differences 
between  the  qualities  of  “tasks”  and  “functions.”  A  function  is  what  is  done  and  a  task  is 
how  it  gets  done.  For  example,  a  function  could  be  described  as  “mission  planning” 
whereas  the  task  would  be  to  “prepare  the  strike  mission  plan.”  The  task  also  has 
associated  subtasks  such  as  “receive  and  review  ops  orders,”  “review  auto  assignment  of 
weapons  to  targets,”  or  “review  and  edit  schedule.”  The  auto  assignment  task  is  supported 
by  the  system  functions  that  calculate  the  best  weapon-target  pairing.  These  types  of 
functions  were  termed  “task  services”  in  MMWS.  Tasks  were  defined  as  processes 
involving  various  levels  of  human  intervention,  while  functions  could  be  either  fully 
automated  computations  or  have  human  involvement. 

During  the  process  of  defining  MMWS  tasks,  a  taxonomy  of  work  tasks  was  created 
and  then  evolved  over  time  as  tasks  were  defined,  created,  deleted,  combined,  or  separated. 
This  happened  over  a  period  of  several  months  as  the  work  environment  and  task  products 
became  better  defined. 

This  evolution  was  necessary  as  the  design  team  completed  the  initial  task  description 
process.  This  definition  and  refinement  process  was  supported  by  teams,  comprising 
SMEs,  human  factors  engineers,  and  computer  scientists.  The  role  of  each  discipline  was 
valuable  as  the  computer  scientist  was  concerned  about  how  to  computationally  model  the 
task;  the  SME  carried  the  perspective  of  real-world  constraints,  procedures  and  operations; 
and  the  human  factors  engineer  presented  the  perspective  of  design  impact  on  human 
performance. 

The  task  definition  process  must  also  remain  flexible  through  early  design  stages.  Some 
work  activities  initially  defined  as  tasks  requiring  human  processing  later  became  more 
fully  automated  after  further  study  found  analysis  methods  to  create  reliable  task  products 
without  human  intervention.  These  tasks  then  became  task  services  in  support  of  other 
tasks.  Thus,  function  allocation  was  not  a  one-time  event,  but  instead  involved  the  creation 
of  a  set  of  hypotheses  that  were  refined  as  task  methods  were  created  and  matured.  The 
process  of  defining  each  of  the  major  task  classes  is  described  in  the  following  sections. 


20.3.2  Task  Properties 

The  next  step  in  the  task  coverage  analysis  process  was  to  conduct  a  task  definition 
exercise  for  all  of  the  tasks  within  the  five  classes  covered.  This  results  in  a  requirements 
definition  that  fully  considers  unique  task  properties.  A  special  section  follows  later  for 
human  support  tasks.  Communication  tasks  are  combined  with  mission  tasks  in  this 
discussion.  The  other  three  classes,  mission,  work  space  computer  management  and 
control,  and  work  management  tasks  are  covered  in  this  section. 

Mission  Tasks  are  the  workload  producing  components  that  are  typically  addressed  in 
naval  system  specifications  involving  human  control  elements.  The  mission  tasks  provide  a 
structure  for  analysis  and  development  of  design  approaches  toward  each  task  goal. 
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The  MMWS  analysis  for  mission  tasks  was  difficult  because  current  naval  systems  have 
minimal  task  design  documentation  (Osga,  1989).  Another  difficulty  confronting  the 
analyst  was  the  sparse  information  regarding  future  shipboard  tasks.  The  analyst,  therefore 
had  to  take  the  following  steps: 

1.  Abstract  information  from  current  task  methods 

2.  Project  design  and  technology  properties  forward  in  time  for  new  tasks 

3.  Reanalyze  the  newly  designed  task  structure 

Air  defense  mission  tasks  initial  listings  of  mission  tasks  were  reviewed  (Osga,  1989)  as 
were  function  analyses  for  land  attack  and  air  missions  [Naval  Surface  Warfare  Center 
(NSWC),  1997, 1998].  An  initial  set  of  tasks  was  derived  when  a  design  reference  scenario 
was  developed.  The  reference  scenario  served  to  focus  the  larger  set  of  possible  functions 
and  tasks  down  to  a  manageable  set  under  the  scope  of  the  project.  The  types  of  mission 
tasks  analyzed  were: 

•  Visually  identify  (VID)  all  unknown  air  contacts  within  a  defined  area  of  responsi¬ 
bility  (AOR). 

•  Escort  air  contacts  from  threat  country  with  aircraft-carrier-based  defensive  counter 
air  (DCA). 

•  Issue  warnings  to  threat  country  aircraft. 

•  Conduct  positive  identification  of  air  contacts  unable  to  VID  by  correlating  indica¬ 
tions  and  warning,  electronic  emissions,  profile,  point  of  origin  or  initial  detection,  air 
tasking  order  and  interrogate  friend  or  foe  signal  (IFF)  received. 

•  Convey  internal  communications  and  external  communications  with  air  warfare 
commander,  DCA,  and  carrier. 

•  Conduct  weapon  engagement  in  self-defense. 

Within  these  types  of  tasks,  mission  task  labels  were  defined  as  a  “verb-noun”  phrase  for 
consistency.  Task  verbs  such  as  “prepare . . . ,  check . . . ,  deliver . . . ,  review .  . . ,  order . , . , 
issue ...”  are  descriptive  of  the  type  of  work  activity  being  performed.  The  task  noun  can 
indicate  the  product  of  the  task,  e.g.,  a  “level  1  query,  level  II  warning,  new  track  report, 
engagement  order,  etc.” 

Work  space  computer  management  and  control  tasks  involve  the  workload  that  is 
inherently  part  of  operating  within  the  computing  environment.  In  a  graphic  user  interface 
(GUI)  environment,  workload  may  be  induced  by  tasks  such  as  searching  for  files, 
organizing  windows,  de-cluttering  displays,  moving  and  navigating  between  windows,  etc. 
If  the  designer  is  satisfied  with  accepting  an  off-the-shelf  GUI  without  consideration  to 
impact  on  workload  or  performance,  then  the  system  design  is  accepting  a  given  level  of 
performance.  Typical  computer  control  tasks  include  the  selection  of  displayed  objects, 
resizing  of  windows,  movement  of  objects,  copy  and  paste  text  between  windows,  search 
for  windows,  files,  objects,  etc.  The  MMWS  design  included  changes  to  the  standard 
“desktop”  approach  based  on  previous  research  conducted  with  similar  task  conditions 
(Osga,  1995.)  The  HCI  design  features  were  used  to  reduce  workload  for  computer  work 
space  management. 


20.4  HUMAN  SUPPORT  TASK  REQUIREMENTS  755 


Work  management  tasks  include  the  management  of  work  activities  with  regard  to  work 
sequence,  task  prioritizing,  multiple  tasks  time  sharing,  and  scheduling.  This  work 
includes  the  transition  between  tasks  and  decisions  regarding  activity  prioritization,  e.g., 
recognizing  what  is  important  to  do  now  versus  what  can  be  delayed.  Individual  work 
management  includes  decisions  regarding  multiple  task  time  sharing — when  to  shift 
resources  from  one  task  to  another.  Experts,  based  on  training  and  experience,  create  a 
background  of  work  environment  knowledge  that  contains  individualized  patterns  and 
rules  about  task  start,  break,  and  stop  points. 

Example  20.3  Expertise  in  Work  Management  Tasks  An  expert  knows  through  repeated 
task  experience  that  “step  3  ”  in  the  process  is  a  good  time  to  pause  for  rest  or  to  shift  attention 
to  another  task  because  of  on-the-job  knowledge  gained.  The  expert  anticipates  that  the  next 
step  requires  a  process  that  takes  several  minutes  of  other  system  resources  (e.g.,  automation 
or  another  user).  Thus,  the  expert  gains  experience  on  the  systems’  timing  and  dynamics  and 
can  better  schedule  attention  resources  during  multitasking  work  events. 

Another  important  aspect  of  work  management  is  the  knowledge  of  when  to  begin  tasks 
or  sometimes  when  to  terminate  them  prematurely.  Tasks  appropriate  in  one  context  may 
be  deleted  during  another.  The  system  design  versus  cost  trade-off  for  work  management 
tasks  is  the  cost  of  training  and  developing  user  expertise  developed  over  time  with  reliable 
repetition  versus  the  cost  of  developing  system  support  features  that  aid  in  reliable  work 
management. 


20.4  HUMAN  SUPPORT  TASK  REQUIREMENTS 

Human  support  task  requirements  are  one  of  the  major  classes  of  tasks  included  in  the  total 
task  coverage  of  the  MMWS.  Special  features  needing  attending  in  the  development  of 
human  support  task  requirements  are: 

1.  Maintaining  situation  awareness  (SA) 

2.  Attention  management 

3.  Decision  making 

4.  Working  memory 

5.  Task  interruption 

6.  Supervisory  control 

7.  Ergonomics 

20.4.1  Maintaining  Situation  Awareness 

Situation  Awareness  is  a  human  process  of  information  collection,  filtering  and  storage, 
interpretation,  and  reaction.  System  aiding  can  be  provided  for  various  types  of  SA 
sampling,  storage,  and  retrieval  activities.  Jones  and  Endsley  (2000)  refer  to  three  levels  of 
SA  as: 

Level  1:  Perception  of  Elements  in  Environment  Elements  are  perceived  within 
a  volume  of  time  and  space.  Tasks  utilize  visual  search,  filtering  of  important  task 
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information  from  peripheral  visual  “noise,”  and  auditory  sampling  from  multiple  circuits. 
All  are  part  of  the  sampling  process  to  continually  update  human  awareness. 

Level  2:  Comprehension  of  Their  Meaning  Implies  that  information  presented  is 
compared  to  the  current  and  near-term  goal  states  of  mission  tasks  and  activities  to 
determine  the  significance  of  events  relative  to  goals.  The  result  includes  decisions  to  start 
delay,  or  cancel  task  activities. 

Level  3:  Projection  of  Their  Status  in  Near  Future  This  level  implies  that  there  is 
a  temporal  nature  to  decision  making  and  that  activities  may  be  launched  or  altered  based 
on  projections  into  the  near-term  future.  In  air  defense  missions,  this  implies  issuing 
warnings  or  reports  or  deciding  that  such  reports  are  not  warranted.  There  is  evidence  that 
users  build  a  story  (or  mental  model)  based  on  the  operating  environment,  expected  events, 
observed  events,  and  compare  this  to  past  experiences  in  their  decision-making  training  or 
operational  experiences  (Klein,  1993). 

Problems  in  mission  performance  may  appear  when  errors  occur  in  SA,  producing  a 
mismatch  between  the  user’s  mental  model  of  the  situation  and  the  actual  situation.  Jones 
and  Endsley  (2000)  refer  to  “representational  errors”  when  information  has  been  correctly 
perceived  but  the  significance  of  various  pieces  of  information  is  not  properly  understood, 
meaning  problems  with  level  2  SA.  In  air  defense,  environment  cues  that  an  aircraft  is 
potentially  hostile  may  be  overlooked  in  favor  of  evidence  that  it  is  a  commercial  airliner,  if 
the  event  was  unexpected  that  a  hostile  should  be  in  that  location  or  if  there  is  speed, 
altitude,  or  position  data  suggesting  “commercial  air.”  The  system  requirement,  therefore, 
is  to  provide  information  in  a  manner  that  prompts  the  user  to  be  attentive  and  aware  of 
conflicting  task  data— providing  track  identification  evidence  both  for  and  against  the 
current  track  identification  state.  The  designer  must  also  create  methods  to  support  user 
understanding  and  projection  of  events  in  the  near  future. 

20.4.2  Attention  Management  Requirements 

Attention  Management  is  a  critical  support  activity  invoking  human  cognitive  and  visual 
skills.  With  increasing  knowledge  and  skill  of  the  work  environment,  the  human  processor 
is  better  able  to  determine  the  importance  of  work  events  and  to  disregard  background 
stimulus  noise.  Human  attention  resources  are  limited  and  are  quickly  forced  to  time-share 
multiple  events  (visual,  auditory)  in  most  tactical  situations.  The  human  processor,  while 
conducting  task  A,  must  preattend  and  be  ready  for  task  B.  Experts  develop  “work  habits” 
as  methods  for  moving  attention  resources  between  task  activities.  The  degree  to  which  the 
system  effectively  supports  these  processes  reduces  human-system  performance  variance 
across  the  spectrum  of  users  who  possess  varying  degrees  of  visual  search  and  attention 
management  skills.  A  significant  requirement  is  to  guide  attention  at  an  appropriate  level 
of  intrusion  into  the  user’s  work  focus  using  both  visual  and  auditory  stimuli. 

20.4.3  Decision-Making  Requirements 

Decision  making  in  naval  warfare  varies  according  to  the  nature  of  the  warfare  environ¬ 
ment  (e.g.,  rules  of  engagement,  operational  orders,  battlegroup  firing  status,  and  type  of 
warfare:  anti-air  defense,  air  offense  and  strike,  land  attack  strike).  In  recent  years,  much 
attention  has  been  paid  to  the  single-ship,  single-threat  scenario  following  the  USS 
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Vincennes  incident  in  1988.  During  the  1990s,  the  Tactical  Decision  Making  Under  Stress 
(TADMUS)  program  studied  air  defense  tasks  with  respect  to  the  identification  process 
and  displayed  information  to  support  decision  making  with  ambiguous  ID  information 
(Morrison  et  al.,  1997).  The  Vincennes  incident  review  showed  that  data  within  the  combat 
system  (such  as  decreasing  altitude  of  an  aircraft)  does  not  translate  directly  to  information 
for  system  users  if  the  displays  and-  information  presentation  do  not  clearly  present 
historical  trend  data. 

When  operating  in  an  international  battle  group  under  defined  doctrine  and  rules  of 
engagement,  the  decision-maker’s  actions  must  conform  to  operational  rules.  As  the 
situation  changes  from  peacetime  to  hostilities,  the  decision  rules  change  but  the  response 
methods  with  each  task  should  remain  stable.  A  watchstation  design  human  interface  must 
support  all  types  of  tactical  situations,  ranging  from  a  “single  possible  threat  in  peacetime” 
situation  to  the  “multiple  threat  hot  war  situation.” 

Important  requirements  must  be  addressed  with  respect  to  information  gathering  and 
management  for  decision  support.  With  an  increased  system  functional  role  in  information 
gathering  and  synthesis,  the  nature  of  task  activity  for  the  user  changes  from  the  current 
“information  gathering  mode”  to  the  “monitor  of  intelligent  automation”  mode.  Table  20. 1 
presents  a  summary  of  the  changing  nature  of  decision  support  requirements  following  a 
trend  away  from  “manual”  information  gathering  systems  toward  increased  automation  for 
information  management.  MMWS  represents  significant  progress  toward  addressing  the 
requirements  listed  in  Table  20. 1  but  does  not  completely  satisfy  them. 

Increased  dependence  on  automation  support  for  task  information  processing  will  in 
turn  change  the  information  requirements  to  support  the  task  process.  Warfighter  needs  for 
“explanation”  facilities  and  supporting  information  will  evolve  as  systems  become  more 
capable  of  reliable  support  for  multiple  tasks  throughout  the  detect-to-engage  process. 
Freeman  et  al.  (1997)  identify  a  “dual-process”  model  in  which  decision  makers  employ 
either  critical  thinking  or  rapid  recognition  process  depending  upon  the  time,  stakes,  and 
familiarity  of  the  task  and  decision  context.  This  requirement  for  support  of  both  types  of 
decision  processes  indicates  that  MMWS  information  displays  must  support  each  decision 
strategy.  See  Example  20.4. 


Example  20.4  Change  in  Automation  Trust  and  Decision  Processes  over  Time  A  reliable 
identification  method  that  reports  a  track  identification  based  upon  comparing  the  track 
information  to  battle  group  identification  parameters  may  initially  be  monitored  or  even 
questioned  by  users  (using  critical  thinking)  who  will  visually  check  each  ID  parameter  to  see 
if  it  conforms  with  the  battlegroup  rules.  If  the  method  is  highly  reliable  (e.g.,  the  system 
repeatedly  creates  IDs  that  match  the  battle  group  ID  rules),  the  occurrence  of  such  user 
checks  will  diminish  (e.g.,  they  will  shift  toward  using  rapid  recognition  processing). 

Thus,  the  decision-making  requirements  for  MMWS  were  stated  as:  (1)  provide  task 
summary  products  for  rapid  recognition  processing  and  (2)  provide  task  amplifying 
information  to  aid  in  critical  thinking  processes  when  time  is  plentiful,  stakes  are  high, 
and  familiarity  with  the  task  is  low. 

The  requirements  listed  in  Table  20. 1  change  the  user’s  role  from  the  current  paradigm 
of  checking  details  of  incoming  tactical  data  streams  using  vigilance  and  cognitive 
storage/recall  skills  (critical  thinking  detailed),  to  the  role  of  strategic  decision  making 
for  more  global  mission  goals  (critical  thinking  globally).  The  user  checks  and  confirms  or 
denies  mission  actions  recommended  by  automation  support  (rapid  processing).  With 
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reliable  system  performance,  the  user  digs  into  the  background  information  only  if 
workload  allows,  or  the  user  questions  the  result,  or  the  decision  has  serious  mission/ 
safety  consequences.  Freeman  and  Cohen  (1998)  discuss  the  decision  tasks  and  critical 
decision  points  for  anti-air  warfare  in  the  context  of  several  currently  fielded  systems. 
MacMillan  et  al.  (1997)  define  critical  decision  points  for  air  defense  warfare  in  a  review  of 
current  air  defense  methods  for  initial  MMWS  design.  The  watchstation  mission  task 
information  was  designed  to  address  many  of  these  critical  decision  points. 

20.4.4  Working  Memory  Requirements 

Tasks  that  evolve  over  time  involve  human  cognitive  processes  in  short-term  or  working 
memory.  Information  that  is  processed  by  visual  and  attention  systems  is  temporarily 
stored  while  the  task  goal  is  active.  Problems  in  storage  and  retrieval  may  appear  when 
stored  information  content  is  similar  (Fowler,  1980). 

Example  20.5  Information  Lost  in  Working  Memory  A  previously  mentioned  course 
change  with  track  7150  is  confused  and  reported  as  a  change  in  track  7157  or  a  few  moments 
later  a  course  heading  of  310  is  recalled  as  030.  A  common  theme  in  “number  reversal” 
during  voice  communications  may  be  lack  of  common  visual  cues  at  each  end  of  the 
conversation  to  augment  the  visual  information.  In  today’s  command  centers,  information  such 
as  electronic  warfare  emissions  may  only  be  available  to  a  single  user  at  a  specific  workstation 
designed  to  receive  that  information,  and  results  may  be  only  transferred  by  voice  to  decision 
makers.  Without  immediate  note  taking  upon  delivery,  such  information  is  easily  degraded  in 
or  lost  in  working  memory,  perhaps  within  10  to  20  seconds  after  arrival  (Wickens,  1987). 

System  design  features  must  be  used  to  unburden  working  memory,  including  storage  and 
retrieval  of  visual  information  to  augment  transient  auditory  information.  Also,  a 
combination  of  numeric  and  spatial  information  presentation  for  track  objects  supports 
both  verbal  and  spatial  working  memory  storage. 

Example  20.6  Compensation  for  Short-Term  Working  Memory  Overload  by  Note 
Taking  An  example  of  short-term  task  overload  in  working  memory  may  be  manifested 
in  either  the  repetition  or  forgetting  of  task  events.  Without  computer  assistance,  system  users 
try  to  compensate  for  memory  limitations  through  note  taking.  Observations  of  operators  in 
action  indicate  that  some  write  down  notes  and  others  do  not  (Hildebrand,  2000),  but  there  is 
no  known  data  on  the  effects  of  note  taking  on  task  outcomes. 


System  design  features  that  can  alleviate  memory  loading  include  features  that  keep  track 
of  information  changes  over  time  and  clearly  present  past,  present,  and  planned  task 
events.  The  MMWS  Response  Planning/Manager  is  an  example  of  a  design  feature  that 
provides  a  visual  time  review  of  tasks  planned,  proposed,  in-progress,  and  accomplished. 
In  today’s  systems  this  can  only  be  accomplished  by  note  taking  or  recall  from  short-term 
memory. 


20.4.5  Task  Interruption  Requirements 

Mission  demands  for  real-time  multitasking  require  increased  designer  focus  on  supportive 
workstation  tools  that  take  into  account  human  limitations  resulting  from  multitasking  and 
the  disruptive  effects  of  interrupting  ongoing  tasks.  McFarlane  (1997)  refers  to  task 
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interruption  as  a  process  of  coordination  between  human  and  machine.  To  support  this 
coordination  workstation,  designs  must  include  software  that  accounts  for  task  interruption 
and  subsequent  user  refocusing.  The  MMWS  alleviates  short-term  interruption  effects  by: 

1.  Providing  low- workload  task  reaccess  using  multiple  screens 

2.  Keeping  relevant  information  together  for  the  task  without  user  burden 

3.  Providing  visual  cues  of  changes  and  highlighting  of  information  changed  since  the 
user  last  checked  the  information 

Another  important  design  requirement  is  the  method  of  design  for  interruption  alerts 
that  change  user  task  and  attention  focus.  Software  methods  must  be  developed  that 
consider  the  context  of  the  interruption  across  multiple  events.  An  event  may  appear  to  be 
important  to  require  an  interruption  of  the  user  when  considered  in  isolation  but  not  be 
worthy  of  interruption  when  other  life-threatening  tasks  are  also  present.  Thus,  the 
requirement  for  context-sensitive  alerting  is  present.  The  design  approach  of  whether  to 
interrupt  abruptly  or  provide  more  subtle  interruption  cues  depends  on  mission  context  and 
time  criticality  of  the  task  events,  taken  in  context  within  the  mission  focus.  This  requires 
interruption  in  the  form  of  visual,  auditory,  or  haptic  cues  that  inform  the  user  beyond  the 
simple  auditory  alert  buzzer  used  in  many  systems  today.  A  multilevel  alerting  system  has 
been  proposed  for  the  MMWS  project,  allowing  a  wide  range  of  interruption  possibilities 
(Obermayer,  1998).  The  proposed  system  has  yet  to  be  fully  implemented  in  MMWS  and 
tested  with  workstation  operators. 


20.4.6  Supervisory  Control  Requirements 

The  human  role  working  in  cooperation  with  automation  is  variable,  ranging  from:  (1)  task 
monitoring  with  hands  off  to  (2)  task  confirmation  at  the  last  procedural  step  to  (3)  full 
involvement  through  multiple  task  steps.  Task  management  automation  removes  much  of 
the  user  burden  of  task  initiation,  and  other  aids  reduce  the  workload  in  completing  each 
task  procedural  step.  The  degree  of  user  involvement  for  task  supervision  may  be  dictated 
by  task  external  pacing.  With  more  work  time  available  to  focus  per  task,  there  is  more 
opportunity  for  hands-on  work,  but  with  less  time  available  there  is  an  increased  need  for 
intermittent  task  focus  by  way  of  supervision  of  the  automation.  The  workstation  must 
easily  support  both  types  of  work  allowing  the  users  to  adapt  to  changes  in  workload. 
MMWS  provides  several  important  features  to  aid  in  visual  search  and  information 
acquisition  during  supervisory  control  tasks.  The  design  requirement  is  to  provide  relevant 
cues  for  high-level  information  visual  scanning,  supporting  decisions  regarding  the  need  to 
drill  down  into  detailed  information  content.  The  requirements  are  made  more  complex  by 
studies  that  suggest  the  type  of  work  tasks  assigned  to  the  crew  member  should  vary  over 
short  periods  of  time. 


Example  20.7  Continuous  Skill-Based  Tasks  and  Alertness  Neerincx  (1999)  reports  that 
just  10  minutes  of  continuous  skill-based  performance  tasks  can  decrease  performance.  As 
workstations  and  automation  can  be  made  more  capable,  a  newer  design  challenge  emerges  to 
vaiy  tasks  in  ways  that  maintain  crew  alertness  throughout  the  typical  6-hour  watch  session. 
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20.4.7  Ergonomic  Requirements 

The  comfort  and  safety  of  the  system  operator  is  a  critical  design  requirement  for  the 
watchstation  design.  The  console  display  pedestal  must  provide  a  comfortable  work 
environment  for  body  statures  ranging  from  the  2.5  percent;  female  through  97.5  percent 
male  size.  Visual  and  reach  envelopes  for  displays  and  touch-screen  interaction  must  be 
considered  such  that  the  user  can  rest  the  elbow  on  the  desktop  surface  comfortably  and 
reach  the  majority,  of  the  display  surfaces.  Input  devices  must  consider  the  motion  effects 
of  sea  conditions  and  the  possibility  that  the  watchstation  could  be  moving  with  a  rough 
sea  state.  Another  important  consideration  affecting  the  pedestal  design  is  team  arrange¬ 
ments  and  the  ability  for  team  members  to  see  each  other.  The  taller,  bulky  consoles  of 
today  prohibit  face-to-face  interactions  and  force  arrangements  of  crews  into  rows  and 
aisles  of  equipment.  Ergonomic  touch,  reach,  visibility,  and  team  interaction  requirements 
led  to  an  MMWS  design  approach  that  accommodates  tire  physical  statures  listed,  provides 
controls  suitable  for  various  sea  conditions,  and  allows  close-proximity  team  interactions. 


20.5  DYNAMIC  TASK  REQUIREMENTS 

Many  of  the  static  or  qualitative  requirements  for  user  task  support  discussed  in  the 
previous  sections  do  not  account  for  the  dynamic  stages  and  processes  involved  in  task 
completion,  and  the  effects  of  time  and  job  pacing  on  task  progression  and  the  human 
information  processor.  Dynamic  task  properties  include  task  and  job  attributes  that  change 
over  time  due  to  the  rate  of  information  change,  the  loading  of  tasks,  and  the  context  of 
multiple  competing  tasks  occurring  in  the  same  time  continuum.  User  qualities  of  fatigue 
and  alertness  change  over  time  also.  Dynamically  varying  data  sets  and  information 
support  tasks  have  a  time  context  within  the  changing  tactical  environment.  The  degree  to 
which  the  system  designers  can  capture  the  context  and  relevancy  of  the  task  information 
with  respect  to  current  operations  could  make  systems  more  responsive  to  the  users’ 
current  needs.  This  section  discusses  these  important  qualities  of  tasks  in  a  task-centered 
design  approach  from  the  perspective  of  task  timing  and  the  dynamic  life  cycle  of  tasks. 

20.5.1  Dynamic  Task  Timing  and  Pacing 

Frequency  and  repetition  of  task  events  within  the  job  context  play  a  role  shaping  the 
system  design  concepts.  Task  pacing,  vigilance  loading,  and  multiple  task  timing  are 
important  factors  requiring  design  support. 

Externally  Paced  versus  Internal  Pacing  Tasks  that  are  externally  paced  cause 
work-induced  stress.  The  tactical  work  environment  creates  this  stressful  pacing  since 
system  users  have  no  control  over  the  pace  at  which  the  enemy  or  other  tactical  entities 
decide  to  operate.  By  nature,  the  goal  of  an  adversary  is  to  overwhelm  the  opponent.  But 
designers  can  consider  design  options  to  mitigate  the  effects  of  external  task  pacing.  For 
example,  tasks  can  be  designed  such  that  their  workload  could  be  distributed  across  team 
members  if  it  increases  to  unacceptable  levels.  Workload  distribution  is  prohibited  m 
today’s  systems  due  to  strict  assignment  of  tasks  with  specialized  operating  modes  in  each 
workstation.  The  specialized  training  of  today  and  lack  of  ability  to  flex  workload 
decreases  survivability,  given  that  removal  of  key  consoles  or  positions  offers  no 
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replacement.  System  tools  and  architectures  for  information  deliveiy  that  allow  for 
distributed  workload  and-  for  assignment  of  any  task  at  any  station  maximize  survivability 
across  the  entire  ship.  These  design  properties  associated  with  workload  distribution 
should  be  factored  into  ship-level  survivability  and  failure  mode  analyses.  In  MMWS  the 
task  management  system  is  designed  to  reduce  externally  paced  workload  on  any  given 
individual  by  allowing  tasks  to  be  distributed  among  the  team  members.  Voice  and 
auditory  information  tasks  are  often  externally  paced,  and  the  design  can  support  increased 
user  control  over  the  pacing  of  tasks  through  digital  storage  of  audio,  thereby  allowing  the 
task  to  become  internally  paced. 

Vigilance  and  Situation  Awareness  Vigilance  tasks  over  periods  of  time  create 
boredom  and  induce  fatigue.  The  designer  should  consider  system  support  in  eliminating 
vigilance  tasks  wherever  possible.  A  warfare  tactic  sometimes  used  involves  human 
vigilance  and  perception.  An  adversary  may  repeat  training  exercises  for  many  days  or 
months,  until  the  exercise  becomes  the  perceived  “norm.”  When  an  attack  is  planned 
during  a  training  exercise,  the  initial  reaction  is  that  “it’s  another  training  exercise.”  Then 
the  initial  stages  of  attack  are  less  perceptible  from  the  routine  exercises,  which  evolve  to 
not  be  of  high  interest.  The  MMWS  design  focuses  on  system  support  to  reduce  vigilance 
workload  by  automatic  detection  and  triggering  of  tasks.  The  design  attempts  reduce  or 
eliminate  errors  and  risk  emanating  from  situations  where  human  detection  is  the  sole 
method  for  beginning  a  task  process.  The  design  will  need  to  support  human  manipulation 
and  editing  of  the  thresholds  and  external  conditions  desired  for  task  triggering.  Given  the 
complexity  of  these  external  conditions,  the  interface  design  will  present  a  challenging 
problem. 

Long-  and  Short-Term  Work  Task  time  frames  may  vary  from  seconds  to  minutes  to 
hours.  Task  times  will  vary  across  mission  domains  such  as  air  and  land  attack.  Some  tasks 
may  be  time-on-target,  requiring  scheduling  of  task  goals  at  a  specific  time  in  the  future. 
The  design  should  consider  the  varying  time  properties  of  tasks  and  require  the  system  to 
support  multiple  active  tasks  with  different  time  frames — with  the  ability  to  quickly  move 
between  these  tasks  to  update  situation  awareness  or  to  easily  refocus  attention  on  a  task 
product. 

20.5.2  Dynamic  Task  Life  Cycle 

Another  important  set  of  task  properties  relate  to  the  task  life  cycle.  In  the  previous  section 
we  spoke  briefly  of  the  concept  of  task  initiation,  with  respect  to  task  management  work 
activities.  Definition  of  additional  states  in  a  task  life  cycle  are  necessary  to  fully  support 
the  work  process  through  the  life  cycle.  The  life  cycle  phases  in  a  task  may  be  defined  as 
follows: 

Initiation:  The  task  supports  part  of  an  ongoing  mission  activity.  The  task  processing  is 
invisible  to  the  user  and  only  seen  as  part  of  a  list  of  possible  tasks  that  might  occur 
or  that  are  planned  for  in  the  future. 

Activation:  The  task  goal  becomes  active  and  requires  servicing  by  the  user  or  system. 

Assign:  The  task  is  assigned  to  human(s)  or  system  (e.g.,  if  automated). 

Execution:  A  task  product  is  prepared  or  response  activities  are  conducted. 
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Completion-.  The  product  is  finalized,  delivered,  and  delivery  is  confirmed.  Task  events 
or  activities  are  completed  and  results  are  confirmed.  The  instance  of  the  task  is 
complete.  The  general  task  then  goes  into  the  same  pending  state  as  during  the 
initiation  phase. 

Retire:  There  is  no  longer  any  anticipated  near-term  need  for  the  task,  such  that  any 
processing  or  system  activity  associated  with  it  can  be  ended. 

Events  monitored  while  progressing  through  the  life  cycle  can  trigger  decision  support 
tools  or  “behind-the-scenes”  automation  and  services.  It  is  important  to  recognize  that 
today’s  tactical  system  designs  focus  almost  entirely  on  execution.  In  automated  doctrine 
systems  such  as  found  in  the  AEGIS  ship  system,  we  find  some  predefined  activation 
facilities  based  on  tactical  events.  But  many  of  these  system  services  are  seldom  used  as 
they  only  apply  to  tactical  events  that  seldom  occur. 

These  phases  of  task  activity  generate  requirements  to  support  the  human  processor’s 
activity  including: 

Initiation :  Informing  the  human  that  a  task  goal  has  become  active  and  that  work  is 
scheduled  to  be  done. 

Orientation-.  Guiding  the  human  visual  and  auditory  processors  to  and  through  the 
information  required  to  process  the  task,  such  as  reviewing  a  proposed  task  product 
and  the  amplifying  information  to  support  the  product. 

Decision :  Supporting  the  decision  process  for  one  or  several  task  steps  ending  in 
approval,  delay,  or  canceling  of  the  task  product  and  task  goal.  Providing  the 
summary  information,  basis  for  results,  recommendations,  etc.  for  the  task  decision. 

Execution  and  Product  Delivery.  Final  preparations  or  confirmation  of  task  products 
and  approval  of  their  delivery  or  execution. 

Confirmation-.  Clearly  defined  indication  that  the  task  process  is  initiated  or  products 
are  now  sent  and  delivered. 

Transition:  User  decision  process  to  move  to  another  task  activity  and  selection  by  the 
user  of  the  next  task  activity  to  focus  current  attention. 

These  phases  of  task  processing  can  be  compared  to  the  command  and  control  (C2) 
process  models  such  as  the  observe— orient— decide— act  (OODA)  decision  processing  loop 
as  defined  by  John  Boyd  or  Lawson’s  C2  process  model  (see  Allard,  1996).  Lawson’s 
model — sense-process-compare-decide-act — more  closely  represents  MMWS  functions 
but  still  is  incomplete  with  respect  to  defining  confirmation  and  transition.  The  designer  is 
faced  with  the  challenge  of  determining  what  system  support  affords  the  human  informa¬ 
tion  and  decision  processing  in  each  of  the  process  steps  (e.g.,  what  can  the  human  do 
reliably  and  what  can  automation  do?;  how  do  both  cooperate  to  achieve  task  goals?). 
While  some  designers  might  interpret  “observe”  or  “compare”  as  an  inherently  human 
function,  in  MMWS  the  human  first  observes  information  that  has  been  “sensed, 
“processed,”  and  “compared”  (as  in  Lawson’s  model)  to  the  desired  state  of  tasks, 
supported  by  automation  in  the  form  of  task  rules  and  heuristics. 

User  Decision  Paths  There  are  several  decision  paths  the  user  may  take  after  initial 
information  processing.  The  task  completion  process  may  vary  according  to  workload  an 
task  risk  or  mission  criticality.  If  the  user  understands  the  task,  product,  and  goal,  an 


20.5  DYNAMIC  TASK  REQUIREMENTS  765 


judges  the  quality  of  the  product  to  be  sufficient,  the  user  may  move  to  final  execution  and 
satisfaction  of  the  immediate  task  goal.  However,  the  initial  decision  “action”  may  be  a 
decision  to  spend  further  dwell  time  on  the  information  to  decide  whether  it  requires 
further  processing.  Several  factors  may  affect  this  decision.  The  “newness”  or  novelty  of 
the  task  in  the  current  work  context  will  likely  affect  task  processing  strategies.  A  new  task 
usually  warrants  more  investigation  by  the  user  and  longer  orientation  times.  Workload  and 
task  priority  will  also  drive  the  decision  strategy  for  orientation  and  review  of  task 
products.  A  familiar  and  repeated  task  will  require  less  orientation.  The  user  strategy  for 
familiar  and  repeated  tasks  will  lean  toward  a  “naturalistic”  process  of  reviewing  the  task 
information  and  quickly  confirming  the  draft  task  product  and  deciding  if  the  task  is  both 
timely  and  required  in  the  current  mission  context.  The  expert  user  will  recognize  that  the 
pattern  of  information  and  results  drafted  by  the  system  for  a  task  meet  the  current 
requirements  either  for  approval,  delay,  or  cancellation.  Task  risk  is  another  important 
factor  in  the  user’s  decision  process  on  how  much  attention  and  cognitive  processing  to 
allocate  to  the  task.  In  MMWS  the  initial  orientation  phase  involved  a  visual  review  of  a 
task  draft  product,  the  context  of  the  task,  including  user  judgment  on  whether  the  task  is 
to  be  completed,  delayed,  deleted,  or  shed  (passed  to  another  team  member). 

Confirmation  The  process  step  of  “confirmation”  is  omitted  from  the  C2  process 
models  but  in  MMWS  the  requirement  was  addressed  to  provide  feedback  to  the  user 
about  task  processing  beyond  the  immediate  task  execution  action.  The  warfighter’s  visual 
and  aural  senses  must  receive  immediate  confirmation  (visual  or  auditory)  that  the  system 
is  executing  the  task  commands.  Confirmation  information  of  task  completion  must  also 
be  persistent  (able  to  be  revisited)  to  guard  against  possible  degradation  of  confirmation 
information  within  working  memory.  This  loss  or  interference  of  confirmation  information 
retrieval  could  lead  to  task  duplication.  This  requirement  is  addressed  in  the  design  of  the 
response  planner/manager  display  in  MMWS. 

Transition  Task  transition  is  critical  but  not  accounted  for  in  legacy  system  require¬ 
ments  nor  addressed  in  the  C2  models  by  Lawson  or  Boyd.  Delays  or  inefficient  decisions 
during  this  stage  of  processing  can  decrease  performance  reaction  time  on  critical  mission 
tasks.  Without  system  assistance  the  user  is  forced  into  an  intertask  workload  demand  to 
recall  mission  activities  in  progress,  decide  whether  to  scan  for  new  tasks  or  recall  a 
previously  incomplete  task,  and  then  gather  information  to  check  the  status  and  relative 
importance  of  events  to  prioritize  the  next  task  action.  There  can  be  search  paths  and 
strategies  that  lead  to  diminished  results  and  further  waste  workload.  St.  John  and  Osga 
(1999)  showed  that  transition  strategies  for  selection  of  tasks  could  be  improved  by 
providing  task  priority  selection  cues  to  users  for  selection  between  mission  and  time- 
critical  tasks. 

20.5.3  Task  Management  Requirements 

A  goal  of  the  system  design  is  to  match  the  dynamic  task  life  cycle  to  human  information 
processing  and  decision  requirements.  These  must  be  matched  for  each  of  the  major  life- 
cycle  phases  in  task  processing.  Table  20.2  shows  the  major  stages  in  the  task  life  cycle 
paired  with  human  information  requirements.  The  requirements  in  this  table  are  repeated  in 
Table  20.4,  with  design  options  listed  to  address  these  requirements.  The  process  of  “task 
management”  addresses  a  set  of  requirements  that  afford  the  focus  of  user  attention 
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TABLE  20.3  Key  Task  Characteristics  Related  to  Task  Management  Requirements 


Task  Characteristics:  Tasks . . . 

May  have  definable  start/stop  schedules. 

Have  definable  goals. 


Are  grouped  as  parts  of  overall  job  role. 

May  be  user  and/or  system  invoked. 

Have  information  and  control  requirements. 

Are  mission  or  computer  control  focused. 

May  involve  varying  levels  of  automation  from 
full  manual  to  partial  to  fully  automated. 

May  require  one  or  many  databases. 

May  require  one  or  many  software 
applications. 

Will  require  attention  shift  between  multiple 
tasks  in  foreground  and  background 
(parallel). 

Have  definable  cognitive,  visual,  and  motor 
workload  components. 

Will  likely  be  interrupted. 

Should  be  consistent  from  training  to  field. 

Will  evolve  as  missions,  systems  evolve  over 
the  life  cycle  of  the  ship. 

May  be  individual  or  collaborative. 


Design  Requirement:  System  Should 

Monitor  concurrent  loading  and  make 
schedules  visible  to  user. 

Monitor  progress  toward  goals;  offer 
assistance  if  needed;  report  progress 
toward  goals;  allow  user  to  modify  or 
create  new  goals. 

Provide  visual  indication  of  task  assignments 
and  task  “health.” 

Indicate  who  has  task  responsibility.  Invoke 
and  “offer”  tasks  when  possible. 

Minimize  workload  to  access  info,  or  controls. 

Provide  full  top-down  task  flow  and  status  for 
mission  tasks  with  consistent,  short 
multimodal  procedures. 

Provide  visual  indication  of  automation  state 
with  supervisory  indicators. 

Do  not  require  the  user  to  know  which 
database  for  any  task.  Direct  queries 
automatically. 

Require  user  to  know  the  tasks,  not  multiple 
applications;  integrate  information  across 
the  job  versus  application. 

Provide  attention  management  and  minimize 
workload  to  shift  between  task  focus. 

Use  task  estimates  for  workload  distribution 
and  monitoring  among  crew  members. 

Provide  assistance  to  reorient  progress  and 
resources  to  minimize  working  memory 
load. 

Provide  consistent  terms,  content,  goals 
throughout. 

Support  reconfiguration  of  task  groupings  and 
addition  of  new  tasks  as  systems  are 
upgraded. 

Support  close  proximity  and  distant 
collaboration  via  visual  and  auditory  tools. 


throughout  the  task  life  cycle.  Endsley  and  Garland  (2000)  indicate  that,  in  “general 
aviation”  pilots,  task  management,  including  ability  to  accurately  assess  the  importance 
and  severity  of  events  and  tasks  is  an  important  component  of  level  2  SA  (see  Section 
20.4.1).  In  MMWS  a  design  focus  on  task  management  requirements  led  to  definition  of 
task  characteristics  (see  Meister,  1985)  and  projected  (estimated)  characteristics  for  a 
future  naval  system  as  shown  in  Table  20.3  (Osga,  1997).  The  need  for  visual  feedback  and 
guidance  for  task  management  listed  in  the  right  column  of  Table  20.3  led  to  the 
development  of  a  task  management  support  function  in  MMWS. 
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20.6  DESIGN  BY  TASK  REQUIREMENTS 

The  previous  sections  described  how  HSI  provided  assistance  to  the  MMWS  project  using 
a  task-centered  approach.  In  particular,  the  HSI  process  focused  the  designer  on  providing 
user  support  through  the  task  life  cycle,  with  the  critical  contribution  of  establishing  both 
static  and  dynamic  requirements  for  the  four  major  task  categories  (mission,  human 
support,  work  management,  and  workspace  computer  management  and  control).  These 
sections  covered  the  first  major  component  of  the  task-centered  design  (TCD)  process — 
establishing  HSI  requirements.  This  section  and  the  next  cover  the  MMWS  experience  in 
the  second  major  component  of  the  TCD  design  process — creating  TCDs. 

The  creation  of  design  concepts  to  address  the  requirements  for  MMWS  included 
several  key  inputs: 

1 .  Experience  and  Lessons  Learned  for  Similar  Systems  with  Similar  Tasks  Previous 
research  projects  with  similar  tasks  provided  design  input  by  supplying  HCI  tool 
“components”  that  supported  computer  interaction  tasks  (Osga,  1995).  Decision  support 
study  results  provided  a  basis  for  decision  support  methods  (Morrison  et  al.,  1997). 

2.  Innovation  and  Creative  Design  Solutions  The  general  philosophy  of  designing  the 
watchstation  to  support  task  goals  (e.g.,  “task-centered”  design)  was  a  central  theme  for 
innovation  within  each  critical  task  area.  The  dynamic  task  life  cycle,  as  described  in 
previous  sections,  is  supported  by  system  functions  that  account  for  human  capabilities  in 
visual  search,  cognition,  memory,  and  training  issues. 

3.  Traceability  of  Requirements  to  Design  Results  Requirement  lists  were  generated 
and  used  to  focus  concept  design  toward  methods  to  address  these  requirements. 
Traceability  is  particularly  critical  in  new  design,  when  management  seeks  an  explanation 
of  what  requirement  the  design  addresses. 

4.  Iterative  Testing  of  Design  Concepts  with  Users  All  requirements  identified  were 
not  addressed  in  the  initial  concept  design.  Iterative  testing  was  a  critical  part  of  the  design 
methodology  and  focused  the  results  on  products  that  worked  with  the  navy  user 
population. 


Example  20.8  Rapid  Prototype  Refinement  of  Design  Requirements  The  design 
concepts  were  captured  in  task  description  documents  and  design  descriptions.  They  were 
then  turned  into  working  models  using  the  Macromedia™  Director  authoring  software.  This 
software  provided  a  rapid  prototyping  method  to  support  usability  testing.  A  parallel 
development  team  created  a  JAVA-based  software  version,  as  requirements  and  design  were 
further  stabilized.  In  this  manner  the  Rapid  Prototype  version  consistently  fed  design 
requirements  to  the  JAVA  programming  team  as  usability  tests  were  completed. 


A  summary  of  the  MMWS  display  design  is  shown  in  Figure  20.2.  The  four-screen 
watchstation  is  shown  with  an  “information  set”  assigned  to  each  of  the  top  three  screens 
and  the  bottom  center  screen  containing  the  Task  Manager  display  with  other  windows. 
Each  of  these  components  is  described  in  further  detail  together  with  the  requirements  that 
were  addressed  with  the  design  features.  This  description  includes  how  the  design 
addressed  the  requirements  of  the  task  life  cycle  and  decision  support,  attention  manage¬ 
ment,  task  management,  user  navigation,  and  ergonomics. 
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Figure  20.2  MMWS  display  layout  and  task  information  sets. 


Table  20.4  summarizes  many  of  the  design  properties  of  MMWS  in  relation  to  user 
support  through  the  stages  of  the  task  life  cycle.  Each  of  these  task  phases  and  design 
attributes  are  discussed  in  further  detail  in  the  following  sections. 


20.6.1  Task  Initiation  Design 

Task  initiation  is  defined  as  the  initial  processing  of  task  triggering  information  and  ends 
with  the  start  of  the  next  phase  of  calculations  for  draft  task  products.  This  processing  of 
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Ilaik  information  is  invisible  to  the  end  user.  The  user  is  brought  into  the  loop  at  the  end  of 
fte  initiation  process,  when  the  system  identifies  the  presence  of  a  task  to  the  user. 

Hi  The  following  task  initiation  requirements  are  addressed  by  various  design  attributes  of 
ffjje'watchstation. 

life 

R;f  ;l.  Present  Task  Plans  for  User  Inspection/ Editing  The  MMWS  presents  task  plans 
Rising  several  views:  (a)  Top-level  iconic  view  of  all  tasks,  (b)  graphic  view  of  assigned 
Bisks  (coded  by  assignment  to  the  user  or  automation),  (c)  graphic  view  of  plans  within  a 
|fask  (detailed  by  track  if  appropriate),  and  (d)  iconic  view  of  tracks  within  a  task  focus  area 
fgbrted  by  simple  ED  priority).  The  Task  Manager  display  column  headings  (see  Fig.  20.3) 
|  shows  the  current  tasks  assigned  to  the  warfare  team.  The  response  Planner/Manager 
[  display  was  designed  to  allow  user  inspection  of  task  plans  (see  Fig.  20.4). 
ter2.  Provide  Practice  and  Rehearsal  Functions  The  requirement  to  support  task 
Ifesponse  planning  and  practice  was  not  addressed  in  the  current  MMWS  design,  and 
file  plan  was  fixed  for  the  test  scenario  operational  area.  This  design  did  not  allow  any 
[flexibility  in  editing  task  plans  during  the  mission  simulation.  This  requirement  allows  the 
jtiser  to  cognitively  rehearse  mission  responses  and  adapt  the  responses  to  different 
[[operational  areas  and  conditions. 

§P'3.  Monitor  Events  for  Task  Triggers  The  MMWS  simulation  was  designed  to  monitor 
(simulated  shipboard  databases  for  events  and  information  changes,  using  rule-based  event 
'  triggers.  Tasks  are  initiated  in  response  to  predetermined  events,  using  simple  mechanisms 
(and  rules.  The  task  description  documents  generated  for  each  task  contained  details  of 
'prescribed  task  triggers  (Osga  et  al.,  2002b). 

€  Task  Initiation  Design  Summary  Task  initiation  requirements  play  an  important 
(  part  in  the  life-cycle  task  process.  If  the  user  or  system  does  not  initiate  a  task,  the  goal  is 


Maintain  Conduct  AIC  Monitor  Issue  Track  5  Conduct  Respond  to 
SA  Tasking  f.  Air  Situation  Reports  ||  Engagement  Air  Threat 
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Figure  20.3  Task  management  icon  list  display  for  air  defense  tasks. 
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Figure  20.4  Response  planner  decision  support  tool. 


not  obtained.  These  requirements  were  addressed  in  the  MMWS  prototype  by  using 
embedded  task  triggers  for  all  air  defense  warfare  (ADW)  tasks  within  the  scope  of  the 
current  test  mission  problem.  The  triggers  were  fixed  and  not  editable  by  end  users,  but 
they  followed  a  battle  response  plan  agreed  to  by  SMEs  as  reasonable  and  following 
accepted  practice  with  fleet  methods  for  the  scenario.  Task  inspection  information  and 
response  plans  were  provided  using  several  iconic  and  graphic  display  formats. 


20.6.2  Task  Activation  and  Assignment  Design 

Task  activation  may  follow  initiation  and  starts  the  process  of  finalizing  the  task  product 
and  meeting  the  immediate  task  goal.  Activation  can  be  either  manually  performed  by  a 
human  action  or  automated  in  a  fielded  system.  In  MMWS  software  and  design,  activation 
was  manually  performed  in  one  software  version  and  had  automatic  assistance  in  a  second 
version.  Requirements  during  activation  and  assignment  are  as  follows: 

1.  Calculate  Task  Information  and  Draft  Products  When  a  task  was  triggered, 
software  mechanisms  were  set  in  motion  to  create  task  products.  These  products  included 
draft  messages  such  as  new/updated  reports,  queries,  and  warnings.  The  design  philoso¬ 
phy  was  that  the  system  would  attempt  to  create  a  “draft”  product  in  best  format  possible, 
allowing  for  user  inspection  and  approval  of  the  draft.  The  current  software  design  did  not 
address  user  editing  of  draft  products.  Some  tasks  did  not  involve  products  for  delivery,  but 
for  inspection,  such  as  an  update  to  operational  orders  or  rules  of  engagement  that  required 
user  cognizance.  The  product  was  formatted  with  text  changes  colored  since  the  last 
inspection  performed  by  the  user. 
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2.  Determine  Which  Team  Member  Gets  Task  Assignment  The  initial  ADW  design  did 
not  address  assignment  by  workload.  The  tasks  were  preassigned  as  designated  by  SMEs’ 
judgment  of  appropriate  assignments.  The  limiting  factor  on  task  assignment  was  related 
to  the  monitoring  of  ship  audio  circuits.  The  various  circuits  needed  an  assigned  operator 
to  monitor  replies  from  external  sources — other  ships,  aircraft,  etc.  The  assignment  of  a 
single  person  to  a  single  circuit  work  strategy  significantly  limited  workload  distribution 
and  task  assignment  for  tasks  associated  with  communications  events.  This  also  prohibited 
the  distribution  and  leveling  of  workload  across  the  team  as  originally  planned  for 
MMWS.  While  there  was  considerable  controversy  among  the  MMWS  design  team  as 
to  how  communications  might  be  handled  in  the  future,  the  limitation  of  workload 
distribution  represented  a  worse-case  design  condition  basis  that  communications  external 
to  the  ship  would  be  handled  using  today’s  voice  technology.  Members  of  the  design  team 
could  envision  digital  messaging  and  transfer  information  to  and  from  the  ship  in  ways  that 
would  lessen  the  workload  restrictions  for  some  types  of  messages  such  as  “new”  or 
“update  track”  reports.  Other  messages  such  as  directions  to  aircraft  or  warnings  to  aircraft 
were  determined  to  require  an  operator  dedicated  to  getting  the  replies  from  the  external 
aircraft.  The  task  demands  for  external  communications  must  be  given  serious  considera¬ 
tion  in  determining  workload  distribution  aboard  future  ships. 

3.  Provide  Appropriate  Visual  and  Aural  Attention  Cues  to  Guide  User  to  Task 
Launching  When  a  task  was  initiated,  three  display  events  occurred:  (1)  An  icon  was 
presented  on  the  task  manager  (see  Fig.  20.3).  (2)  An  icon  could  appear  on  the  peripheral 
task  indicators  if  the  task  was  at  the  top  of  the  queue  for  that  task  category.  (3)  An  instance 
of  the  task  could  appear  as  a  small  amplifying  information  summary  window  in  the  list  of 
windows  for  a  task  category  (see  “priority  tracks  awaiting  completion”  in  Fig.  20.2).  Aural 
cues  were  used  in  usability  studies  to  represent  different  task  attributes,  and  it  was. 
determined  that  they  did  not  add  benefit  to  task  launching  performance  while  creating 
unnecessary  distraction.  Auditory  cues  were  delegated  to  a  supportive  role  if  the  task 
response  exceeded  a  certain  time  limit  and  urgency  requirement. 

20.6.3  Task  Execution  Design 

During  execution  the  users’  attention  processes  are  focused  on  the  task  requirement  when  a 
decision  has  been  made  to  begin  task  execution.  Task  execution  involves  the  process  of 
supporting  control  actions  and  decisions  relevant  to  satisfying  the  task  goal(s).  Execution 
includes  the  user  launching  the  task  to  populate  displays  and  windows  with  the  task 
information  set,  and  then  the  user  monitoring  or  executing  the  task  as  appropriate.  The 
final  step  to  execution  would  be  delivery  or  cancellation  of  the  task  product.  Execution 
could  also  be  delayed  and  then  restarted  at  a  future  time. 

The  MMWS  design  included  multiple  displays  to  allow  the  user  to  easily  time-share 
display  allocation  between  concurrent  tasks  without  requiring  changes  to  a  single  display 
to  transition  between  tasks.  The  need  for  task  time-sharing  varies  according  to  mission 
demands,  and  at  times  of  low  workload,  a  single  display  may  suffice.  The  three  displays 
were  considered  supportive  in  a  high  workload  environment.  They  were  also  selected  and 
positioned  on  the  basis  of  ergonomic  requirements  (see  Section  20.4.7). 

Example  20.9  Flexible  Control  Methods  to  Launch  Tasks  To  aid  in  quick  performance 

reaction  and  reduce  visual  search,  redundant  methods  were  provided  to  launch  tasks.  These 

methods  were  based  on  user  cognitive  and  visual  strategies  envisioned  for  task  processing. 
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Several  methods,  including  task  icons,  task  bars,  and  pop-up  windows,  were  provided  to 
launch  a  task.  Several  of  these  task  launch  methods  provided  a  similar  support  strategy  to 
launch  a  sequence  of  task  events  allowing  the  operator  to  maintain  visual  focus  on  a  single 
display  area  to  accomplish  a  sequence  of  tasks.  These  methods  allowed  the  user  to  work  within 
a  task  type,  “task  family,”  or  to  move  between  task  families  and  types. 

Quick  assessment  and  flow  through  task  processing  is  done  by  making  visual  search 
and  visual  work  flow  through  the  task  efficient.  Visual  work  must  flow  within  a  display  and 
flow  across  displays.  In  the  design  of  display  layouts  there  are  no  perfect  answers,  but 
instead  there  are  many  layouts  that  could  foster  effective  task  flow.  The  MMWS  design 
supports  a  user  strategy  of  continued  work  within  a  task  (single  display),  quick  sampling  of 
the  larger  work  activity  (Task  Manager  and  three  displays),  and  switching  rapidly  between 
tasks  (visual  shift  to  primary  displays).  The  workload  induced  by  a  display  visual  shift, 
combined  with  common  formats  and  common  placement  of  similar  information  (such  as 
task  products),  would  be  less  than  that  required  to  access,  remember,  and  locate 
commands/menus  to  navigate  between  tasks.  This  simple  visual  shift  between  tasks 
should  be  less  disruptive  to  cognitive  processing  of  higher  level  mission  activities. 

Example  20.10  Supervisory  Displays  There  are  several  supervisory  “layers”  provided  in 
MMWS  design  to  aid  in  fast  assessment.  The  highest  layer  is  across  an  entire  display,  where 
differences  in  color  provide  visual  cues  for  conflicting  or  homogeneous  information  on  ID. 
Supervision  requires  visual  and  cognitive  processes  to  first  sample  information  and  second  to 
decide  when  to  dig  deeper  into  a  task  processing.  A  key  information  issue  is  the  urgency  and 
mission-critical  nature  of  the  task  or  information.  Information  that  is  neither  urgent  nor 
mission  critical  is  left  for  future  processing  while  urgent  or  critical  information  is  given 
attention.  The  first  layer  of  user  processing  is  by  position  and  color.  For  example,  position 
coding  has  task  family  positions  constant  in  the  Task  Manager  (TM)  display  and  task  icons 
placed  and  coded  on  the  TM  list  according  to  urgency;  whereas  color  coding  is  used  to  aid  in 
quick  scanning  such  as  for  conflicting  ID  information  by  using  multiple  hues.  Other  design 
methods  include: 

•  Summarize  information  to  quickly  orient  user.  Kellmeyer  and  Osga  (2000)  report  that  the 
Basis  of  Assessment  window  (see  Fig.  20.5),  with  its  color  coding  and  consistent 
summary  of  ID  information,  is  one  of  the  most  useful  information  summary  displays  on 
the  MMWS. 

■  Provide  decision  support  and  produce  “draft”  task  products  for  review  before  execution. 

•  Provide  task  product  summaries — ready  for  execution,  delivery  appropriate  for  automa¬ 
tion  approval  level. 

•  If  task  is  suspended,  record  state  of  task  when  suspended.  Continue  task  processing  if 
appropriate.  Monitor  task  state  and  inform  user  if  appropriate  when  to  reengage  task. 

•  Conduct  final  task  processing  and  provide  feedback  that  task  executed  properly — 
message  sent,  product  delivered. 

•  Provide  function  to  cancel  a  task  and  remove  it  from  the  display  and  record  in  any 
historical  task  documentation  that  task  was  canceled  by  user. 

20.6.4  Task  Transition  Design 

Task  transition  design  includes  support  for  decisions  about  work  strategy  and  direction  of 
attention  toward  available  task  opportunities.  Transition  involves  a  change  of  immediate 
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Figure  20.5  ID  basis  of  assessment  display.  Right  side  of  window  shows  ID  history  parameters  and 
colored  bars  indicate  change  over  time.  Left  side  shows  current  threat  positive  for  selected  track. 

user  focus  from  a  specific  task  goal  toward  identifying  the  broader  scope  of  task  goals  to 
be  accomplished,  followed  by  a  decision  whether  to  continue  sampling  for  task  opportu¬ 
nities  or  to  begin  to  work  to  accomplish  a  specific  task  goal. 

1.  Provide  Direction  and  Cues  to  the  Next  Most  Important  Task  to  Be  Executed 
Several  visual  cues  were  used  to  provide  information  on  the  remaining  tasks  to  be  executed. 
The  coding  methods  are  shown  in  Table  20.5.  On  the  tactical  display  window,  symbols 
were  filled  if  an  incomplete  task  was  remaining  and  unfilled  if  no  tasks  were  pending. 
Thus,  if  New  Track  Report  task  was  currently  selected,  all  filled  symbols  shown  were  those 
pending  a  new  track  report.  If  Monitor  Air  task  was  selected,  all  pending  tasks  were  shown 
for  suspect  and  unknown  tracks.  In  the  periphery  of  the  tactical  display  the  task  icons  were 
listed  showing  the  top  task  in  each  task  family,  and  the  Amplifying-Information  windows 
showed  a  sorted  list  of  tracks  within  the  selected  task.  Table  20.6  lists  the  triggers  and 

TABLE  20.5  Visual  Cues  to  Aid  Task  Transition 


Display  Location 
Tactical  situation  map 


Tactical  situation  display 
peripheral  area 
Tactical  situation  periphery 

Response  planner/manager 
(RPM) 

Task  manager  (TM) 


Type  of  Visual  Cue 
Filled  symbols 


Task  icon 

Amplifying  information 
windows 

Show  next  suggested  task 
with  highlighted  text  on 
task  bar. 

Task  icon  with  time  or 
urgency  color  border  on  the 
task  icon. 


Comments 

Indicate  task  in  queue 
awaiting  processing.  If 
monitor  air  situation  then 
only  suspect  or  unknown 
symbols  with  pending  tasks 
filled. 

Show  top  task  icon  from  each 
task  family. 

Show  sorted  windows  for  top 
7  tracks  in  the  selected  task 
family. 

A  circle  appears  on  the  bar  if 
someone  on  the  team 
activates  a  task  and  it  is  in 
progress. 

Task  icon  border  colors  were 
used.  (See  Table  20.6  for 
coding  rales  by  task  type.) 
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TABLE  20.6  Visual  Cues  for  Task  Urgency/Latency 


Task  Type 


Visual  Cue  Trigger 


New  track  report 
Update  track  report 
I&W  updated 
ATO  updated 
ROE  updated 
Level  I  query 
Level  II  warning 

ESM  tasks 
Maintain  workload 
Monitor  air  situation 


2  minutes — no  response 

3  minutes — no  response 
5  minutes — no  response 


Longer  range  from  ownship 
Medium  range  from  ownship 
Close  range  from  ownship 
No  cues  used 


Type  of  Cue  (lower  to  higher 
urgency  shown) 

Yellow  border  on  task  icon 
Orange  border  on  task  icon 
Red  border  on  task  icon 


Yellow  border  on  task  icon 
Orange  border  on  task  icon 
Red  border  on  task  icon 
No  colored  borders  used 


visual  cues  associated  with  tasks  that  had  a  late  response  or  an  increase  in  urgency  due  to 
the  position  and  heading  of  the  track  in  relation  to  friendly  ships. 

2.  Provide  General  Situation  Awareness  Information,  Update  on  Important  Events 
Since  Last  User  Information  Check  Within  the  limited  air  defense  task  domain  studied, 
several  tasks  were  included  to  provide  an  update  to  situation  awareness  and  changing 
information.  The  system  provided  updates  to  the  indications  &  warnings  (I&W)  status,  air 
tasking  order,  air  warfare  situation  representation  (SITREP)  report,  ship  equipment  status, 
and  rules  of  engagement  (ROE)  as  information  changed  for  these  documents.  Information 
that  changed  since  the  last  user  update  was  shown  using  an  alternate  color  in  the  window. 


20.7  SPECIAL  DESIGN  QUALITIES 

There  are  a  number  of  design  qualities  stimulated  by  the  HSI  process  that  were  integrated 
into  the  product  such  that  the  overall  design  produced  shows  a  strong  focus  on  HCD 
qualities  including: 

•  Design  for  decision  support 

•  Design  for  attention  management 

•  Task  manager  design  concepts 

•  Design  for  user  navigation  and  selection 

•  Design  for  user  ergonomics 

20.7. 1  Design  for  Decision  Support 

The  decision  support  design  principles  used  in  MMWS  were: 

1.  Bring  the  information  to  the  decision  and  summarize  it. 

2.  Clearly  show  any  ambiguity  or  conflicting  information  with  regard  to  the  decision. 

3.  Provide  assistance  in  the  timing,  planning,  and  scheduling  of  decisions. 
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TABLE  20.7  Coding  Methods  Used  in  RPM  Display  for  Decision  Support 
Coding  for  task  name  on  task  “bar” 

Gray  text — task  not  yet  recommended  for  this  type  of  track  and  its  kinematics. 

White  text — task  may  be  recommended  at  future  point  if  track  maintains  same  ID  and  same 
kinematics. 

Black  text — task  is  completed  already  if  task  bar  is  white. 

Coding  for  task  completion  status 
Black  bar — task  completed. 

White  bar — task  has  been  created  (system  or  operator). 

Gray  bar — task  not  initiated. 

Coding  to  keep  record  of  occurences  of  task  for  track 
Open  circle — task  currently  in  process  or  pending. 

Green  circle — task  has  been  completed. 

No  circle  with  white  bar — indicates  that  the  task  was  probably  deleted  by  an  operator. 


An  example  of  these  design  principles  were  shown  with  the  information  sets  that  provide 
the  task  information  for  each  task  goal,  with  color-coding  used  to  show  ambiguous  or 
conflicting  information  related  to  the  track  ID  involved  in  the  task  decision.  Also,  the  TM 
and  response  planner  manager  (RPM)  displays  provided  work  strategy  decision  support 
mechanisms.  Further,  visual  coding  mles  were  used  in  the  RPM  display  to  provide 
decision  support  information  on  work  strategy  to  the  user  as  summarized  in  Table  20.7. 


20.7.2  Design  for  Attention  Management 

Attention  management  is  the  process  of  system  support  to  guide  human  resources  such  that 
those  resources  are  allocated  in  an  efficient  manner  to  the  most  critical  or  urgent  task 
activities.  In  situations  where  no  time-urgent  or  mission-urgent  tasks  are  in  the  queue  to  be 
done,  attention  should  be  guided  toward  information  relevant  to  pending  and  future  task 
goals.  Attention  management  should  be  handled  carefully,  due  to  issues  discussed  earlier 
concerning  task  interruption.  In  MMWS,  a  layered  approach  to  management  included 
(1)  visual  cues  and  (2)  alerts  (visual  and  auditory)  that  supplement  the  visual  cues.  The 
primary  visual  cues  guide  work  flow  and  resource  allocation  between  and  within  tasks. 
Specific  cues  guide  attention  within  a  task.  Many  of  these  visual  cues  have  been  presented 
in  earlier  sections  on  design  for  task  initiation  and  execution.  In  addition  to  capturing 
visual  and  auditory  channels  when  needed,  the  system  must  foster  smooth  and  efficient 
flow  toward  completing  the  work  activity  and  then  through  task  transition.  The  following 
sections  discuss  two  attention  mechanisms  in  MMWS:  task  prioritization  within  the  task 
management  functions  and  alerting  mechanisms.  Two  examples  are  presented. 

Example  20.11  Task  Prioritization  Task  prioritization  schemes  were  proposed  but  not  fully 
implemented  in  the  MMWS  software  during  the  project  time  frame.  A  priority  scheme  was 
proposed  with  four  levels  ranked  from  highest  to  lowest  priority:  (1)  mission  critical  and  time 
critical;  (2)  mission  critical  but  not  time  critical;  (3)  time  critical  but  not  mission  critical;  and 
(4)  neither  time  critical  nor  mission  critical.  This  task  prioritization  scheme  was  not  effective 
by  itself,  and  another  variable  came  into  play  that  did  not  allow  preassignment  of  a  “rank”  to  a 
task  type.  The  object  or  track  involved  in  a  task  could  make  that  task  change  between  levels  of 
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mission  or  time  criticality.  Thus,  a  new  track  report  for  a  track  identified  as  a  commercial  air  at 
some  distance  was  level  4,  while  the  same  report  for  a  suspect  closing  to  the  battle  group 
might  be  level  1.  Then,  a  more  elaborate  prioritization  was  proposed  based  on  various  track  ID 
parameters  (Hildebrand,  1999).  The  detailed  prioritization  methods  were  not  implemented  in 
the  current  MMWS  software,  and  a  simple  scheme  of  first-in,  first-out  was  selected  with  the 
most  recent  task  instance  shown  at  the  top  of  the  display  for  each  task  group.  As  expected,  in 
comments  from  users  following  tests,  users  did  not  approve  this  simple  prioritization  method. 
Further  research  is  warranted  on  best  methods  to  prioritize  and  rank  tasks,  including  methods 
on  how  to  update  the  task  priority  rankings  as  these  priorities  change  in  real  time. 


Example  20.12  Attention  Management  Cueing  Methods  Attention  cueing  supports  the 
process  of  bringing  the  user’s  attention  to  critical  issues  or  problem  tasks.  Cues  were  described 
earlier  to  guide  task  progress  and  transition.  Other  cueing  support  was  provided  to  indicate  late 
or  delayed  tasks  and  information  changes  within  tasks.  The  cues  were  numbered  from  low  to 
high,  ranging  from  a  low  amount  of  visual  and  auditory  stimulus  to  progressively  higher 
amounts  of  stimuli.  Figure  20.6  shows  the  visual  appearance  of  several  graphic  cues.  The  first 
and  primary-type  visual  cues  notify  the  user  of  task  initiation  and  presence,  with  icons  and 
visual  indicators.  Higher  levels  of  cue  stimulation  add  additional  visual  cues  in  a  change  of 
color  for  the  TM  icon  border.  These  cues  were  time-based  and  appeared  within  a  certain 
period  after  no  response  for  a  presented  task.  Higher  intensity  cues  also  involved  the  use  of 
audio  cues  and  blinking  of  the  standard  alert  icon  (a  small  triangle).  The  icons  appeared  in 
static  form  as  shown  on  a  button  or  window  as  shown  in  Figure  20.6  and  then  could  become 
blinking  after  no  response  for  a  given  period.  Lower  priority  alerts  could  be  delayed  if  higher 
priority  alerts  were  present.  The  relative  priority  of  multiple  alerts  across  tasks  becomes  an 
important  issue  when  workload  increases. 

20.7.3  Task  Manager  Design  Concepts 

Design  concepts  related  to  task  management  requirements  are  listed  in  Table  20.8.  Many, 
but  not  all,  requirements  were  addressed  in  the  current  design. 

Task  Manager  Summary  Window  Format  Design  In  order  to  address  require¬ 
ments  related  to  depiction  of  task  state  information,  formats  were  designed  to  depict  tasks 
currently  active  in  the  work  queue.  Early  concepts  addressing  air  defense  task  progress 
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Figure  20.6  Examples  of  visual  alert  cues  (low  priority)  used  in  tasl 
windows. 


20.7  SPECIAL  DESIGN  QUALITIES  781 


RPM — individual  threat  response  summary. 

TM  display — composite  workload  and  task 
icons. 

RPM — range  based,  single  threat  summary, 

TM  display — task  summary  display.  No  user 
modification  in  current  design. 

TM  display  and  workload  indicators. 

TM  display — task  assignment  summary. 

MMWS  context  and  event  monitoring  to 
support  task  initiation. 

Multiple  display  surfaces — maximize  visual 
work  space  (within  5-95%  reach  envelope 
for  touch). 

TM  expand/contract  task  fist  and  task  filters. 

Earlier  TM  designs  indicated  automation  type. 

Removed  for  ADW  when  automation  was 
fixed  for  testing.  Added  for  land  attack. 

Information  sets  provide  information 
automatically  for  task. 

Apply  consistent  procedures  across  different 
tasks. 

Multiple  displays  allow  simple  visual  shift 
between  tasks.  Task  priority  visual  cues. 
Tasks  assigned  to  columns  in  similar 
groupings.  Task  columns  match  display 
assignment. 

Workload  distribution  summary  display  shows 
relative  loading  among  crew  members. 

Highlight  changed  information  when  task  is 
“dormant.”  Reminders  and  notes  tied  to 
tasks. 

Consistent  task  design  across  multiple  tasks. 

Task  groupings  fixed  in  current  design.  Future 
support  should  provide  flexibility. 


Monitor  concurrent  loading  and  make 
schedules  visible  to  user. 

Monitor  progress  toward  goals;  offer 
assistance  if  needed;  report  progress  toward 
goals;  allow  user  to  modify  or  create  new 
goals. 

Provide  visual  indication  of  task  assignments 
and  task  “health.” 

Indicate  who  has  task  responsibility.  Invoke 
and  “offer”  tasks  when  possible. 

Minimize  workload  to  access  info,  or  controls. 


Provide  full  top-down  task  flow  and  status  for 
mission  tasks  with  consistent,  short 
multimodal  procedures. 

Provide  visual  indication  of  automation  state 
with  supervisory  indicators. 

Do  not  require  the  user  to  know  which 
database  for  any  task.  Direct  queries 
automatically. 

Require  user  to  know  the  tasks,  not  multiple 
applications;  integrate  information  across 
the  job  versus  application. 

Provide  attention  management  and  minimize 
workload  to  shift  between  task  focus. 


Use  task  estimates  for  workload  distribution 
and  monitoring  among  crew  members. 

Provide  assistance  to  reorient  progress  and 
resources  to  minimize  working  memory 
load. 

Provide  consistent  terms,  content,  goals 
throughout. 

Support  reconfiguration  of  task  groupings  and 
addition  of  new  tasks  as  systems  are 
upgraded. 


TABLE  20.8  Key  MMWS  Design  Concepts  Related  to  Task  Management  Requirements 


MMWS  Design  Concept  Basis  Design  Requirement 


were  created  in  1989  and  reported  in  Osga  (1995).  Design  concepts  for  the  RPM  display 
from  the  TADMUS  project  were  also  reviewed  (Kelly  et  al.,  1996;  Morrison  et  al.,  1997) 
and  from  research  efforts  following  TADMUS  (Manes  et  al.,  1999;  St.  John  et  al.,  1999). 

The  RPM  display  was  used  to  depict  planned  response  actions  in  air  defense  warfare 
showing  task  duration  and  deadlines  related  to  individual  air  threats.  Additional  informa- 
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tion  was  required  beyond  the  single-threat  RPM  focus  to  address  task  situations  with 
multiple  threats  and  multiple  mission  activities.  The  TM  display  was  created  to  provide  a 
view  of  all  tasks  planned  or  in  progress.  The  TM  air  defense  display  format  differed  for 
long-term  tasks  such  as  mission  plans  or  execution  of  events  that  occurred  over  many 
minutes  and  involved  multiple  steps  in  their  sequence. 

Usability  testing  results  (Kellmeyer  and  Osga,  2000)  indicated  that  visual  depiction  of 
time,  automation,  and  deadline  with  display  scrolling  on  the  task  manager  window  were 
not  beneficial  during  high  workload  periods.  Information  concerning  task  deadlines  and 
schedules  was  not  needed  in  fast-paced  air  defense  tasks.  The  users  simply  wanted  to  see 
current  work  in  the  queue  and  process  the  task  as  quickly  as  possible.  Figure  20.3  shows 
the  simpler  TM  display  with  task  icons.  Simple  icons  were  found  to  be  sufficient  for  air 
defense  mission  task  depiction. 


20.7.4  Design  for  User  Navigation  and  Selection 

Two  important  design  features  include  methods  to  navigate  through  task  procedures  and 
for  selection  of  objects  or  functions.  Five  multimodal  selection  methods  are: 

1.  Redundant  Touch  and  Trackball  Cursor  Movement  The  watchstation  provided 
several  redundant  methods  with  which  to  navigate  the  four-screen  work  space.  Methods 
employed  were  touch,  trackball  for  full  cursor  navigation,  and  partial  navigation  with 
keypad.  Gross  movements  were  aided  by  touch.  With  this  method  it  was  impossible  to 
visually  lose  the  cursor  since  it  would  always  appear  where  the  screen  was  touched. 
Moving  the  cursor  large  distances  between  all  screens  was  easily  done  with  touch.  Fine 
selection  movements  to  select  tracks,  icons,  and  other  GUI  objects  were  done  with  either 
touch  or  trackball.  Selection  of  tracks  was  aided  by  the  advanced  hooking  algorithm  (Osga, 
1991). 

2.  Navigation  on  Task  Manager  with  Keypad  Navigation  on  the  task  manager  was 
also  supported  by  the  keypad.  The  arrow  keys  could  be  used  to  move  between  task  icons 
on  the  TM  and  the  ENTER  key  used  to  select  an  icon  (or  the  select  button  on  trackball). 
The  user  could  proceed  through  most  tasks  with  one  hand  on  keypad  and  one  on  the 
trackball  without  ever  touching  the  screens  or  reaching  to  hook  a  track.  The  default  task 
product  window  and  DONE  or  SEND  function  would  gain  cursor  focus  at  the  end  of  a  task 
allowing  the  select  function  on  the  trackball  to  be  used  to  complete  the  task. 

3.  Track  Search  with  Keypad  Tracks  could  be  hooked  and  located  using  the  search 
function  with  the  numeric  keypad.  With  the  NumLock  set  in  the  “on”  position,  the  user 
typed  a  four-digit  number  in  the  keypad.  A  virtual  keypad  appeared  in  the  top  right  comer 
of  the  tactical  plot  that  showed  what  was  being  typed  and  on  which  plot  the  track  would  be 
hooked.  When  the  ENTER  function  was  selected,  the  track  with  that  number  would  be 
hooked.  Usability  test  feedback  provided  positive  results  for  all  the  methods  used  for 
navigation. 

4.  Prehook  Selection  Methods  and  Information  Prehook  information  refers  to  track 
information  obtained  by  moving  the  cursor  near  the  track  object,  before  a  selection  action 
is  made.  A  dashed  circle  indicated  the  track  that  will  be  hooked  when  a  select  action  is 
made  and  shows  a  small  set  of  summary  information  about  the  track.  When  the  select 
(hook)  action  is  made,  the  circle  changes  to  solid  and  other  auxiliary  windows  present  the 
amplifying  information  for  that  track.  A  select  action  used  either  the  left  trackball  button  or 
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TABLE  20.9  Popup  Menus  and  Methods 


Type  of  Menu 

Method  Accessed 

Notes 

Track  context  popup 

Right  trackball  button 

Cursor  near  track  on  map 

Map  context  popup 

Right  trackball  button 

Cursor  over  map — not  near 
track 

Track  list  popup 

Left  trackball  button,  depress 
and  hold 

Cursor  near  track 

Auxiliary  window  list  popup 

Left  trackball  button,  depress 
and  hold 

Cursor  over  an  unused  part  of 
window— -not  over  button 

a  tap  on  the  screen  with  the  finger.  Dragging  the  finger  or  moving  the  trackball  showed  the 
prehook  indicator  as  the  cursor  was  moved. 

5.  Function  Selection  Methods  Methods  used  to  select  functions  included  variable 
action  buttons  (VABs)  and  popup  windows  including  the  track  contextual  menu,  tactical 
situation  (TACSIT)  map  menu,  track  declutter  menu,  and  auxiliary  window  context  menu. 
Table  20.9  indicates  how  each  pop-up  menu  was  activated. 

20.7.5  Task  Procedure  Design 

The  MMWS  job  design  contains  a  set  of  repeatable  procedures  designed  such  that  tasks 
could  be  launched  by  several  methods.  This  approach  allows  the  user  to  adopt  multiple 
task  flow  strategies  during  task  transition.  The  user  scans  for  task  opportunities,  starts  the 
task  using  several  alternate  methods,  scans  the  task  products  and  information  sets,  and 
makes  a  task  decision  and  transition  to  the  next  task.  Table  20.10  compares  procedures  for 


TABLE  20.10  MMWS  Task  Procedure  Design  Summary 


Procedure  Step 

Basic  MMWS  Method0 

Enhanced  MMWS  Method 

Scan  for  task  opportunities 

Tactical  symbol  color  coding 

Color  coding  and  Task 

for  ID 

manager  icons 

Start  task 

Variable  action  button 

Task  manager  icon 

Track  pull-down  menu 
Tactical  display  peripheral 
icon 

Mini-Amp  info;  selection  (if 
user  stays  within  same  task 
for  repeated  tracks) 

Manual  Variable  action  button 

Collect,  information  for  task 

Visual  scanning 

Decision  support  information 
sets 

Task  decision 

Send  order,  message,  report, 

Send  prepared  order, 

or  read/comprehend 

message,  report,  or 

information 

read/comprehend 

information 

Task  transition 

Visually  scan  and  wait 

Review  next  Task  manager 
icon 

““Basic  MMWS”  refers  to  the  version  with  limited  decision  aids  while  the  “Enhanced”  version  contained  the  foil 
set  of  decision  support  aids. 
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the  Basic  and  Enhanced  versions  of  MMWS.  This  simple  procedural  method  was  able  to 
service  many  different  types  of  tasks,  and  training  was  streamlined  due  to  the  consistency 
across  task  types. 

20.7,6  Design  for  User  Ergonomics 

In  the  spring  of  1998,  the  NEC  Corporation  began  producing  flat-panel  color  liquid-crystal 
displays  with  a  much  wider  viewing  angle.  These  displays  were  selected  for  an  upgrade  to 
the  MMWS  console  configuration.  An  Elographics  guided-acoustic  wave  touch  screen  was 
also  selected.  Initial  foam-core  mockups  of  the  MMWS  pedestal  were  constructed  to 
evaluate  reach  envelopes.  When  the  larger  NEC  displays  became  available  at  a  20-inch 
size,  the  design  was  altered  to  accommodate  them.  Three  displays  were  placed  in  the 
optimum  reach/viewing  envelope  with  adequate  resolution  and  display  area  to  accom¬ 
modate  multiple  tasks.  A  desktop  version  of  the  MMWS  was  used  for  usability  testing 
prior  to  construction  of  the  display  pedestal.  The  final  configuration  is  shown  in 
Figure  20.7. 


# 


20.8  BENEFITS  OF  TASK-CENTERED  DESIGN 

The  benefits  of  the  design  approach  are  seen  with  results  from  individual  and  group 
performance  testing  (Osga  et  al.,  2002a).  Individual  and  group  performance  tests  were 
conducted  with  naval  fleet  operators.  Performance  gains  were  found  for  both  speed  and 
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accuracy  with  improvement  in  SA  and  workload.  Training  was  also  simplified  relative  to 
the  training  requirements  for  similar  systems  currently  in  operation. 

20.8.1  Performance  Testing 

A  team  performance  test  was  conducted  comparing  shipboard  nine-member  crews  using 
today’s  equipment  and  methods  (legacy  team)  to  five-member  crews  using  the  MMWS 
configuration  (HCD  team).  Eight  ship  crew  teams  were  tested  using  the  scenario  aboard 
AEGIS-class  ships  at  pier-side  or  in  land-based  training  sites.  Six  MMWS  crews  were 
tested  with  the  basic-capability  (BC1)  MMWS  and  two  teams  with  the  enhanced- 
capability  (EC2)  MMWS.  The  BC1  version  lacked  some  of  the  dynamic  decision  aids, 
whereas  the  EC2  version  contained  the  full  spectrum  of  aids.  A  realistic  air  defense 
scenario  was  prepared  containing  both  low-  and  high-density  track  periods  to  stimulate 
various  levels  of  tasks  required.  The  scenario  test  used  role  players  who  acted  the  part  of 
aircraft  and  other  ships  in  the  battlegroup.  The  role  players  were  positioned  in  another 
room  separate  from  the  test  teams,  using  voice  communications  simulating  battlegroup 
operations.  The  AEGIS  teams  had  eight  air  defense  members  plus  an  air  intercept 
controller,  responsible  for  vectoring  aircraft.  The  MMWS  teams  had  four  members  with 
a  combination  of  duties  assigned  to  the  smaller  crew  size  (see  Fig.  20.8).  Teams  were 
instructed  to  conduct  air  defense  warfare  tasks  in  accordance  with  the  rules  of  engagement 
and  operational  plans  briefed  during  training  and  as  practiced  during  the  training  exercised 
preceding  the  test.  Primary  operational  tasks  were: 

•  Visually  identify  (VID)  all  unknown  air  contacts  within  a  defined  area  of  responsi¬ 
bility  (AOR). 

•  Escort  air  contacts  from  threat  country  with  aircraft-carrier-based  friendly  aircraft. 

•  Issue  warnings  to  threat  country  aircraft. 

•  Make  positive  identification  of  air  contacts  unable  to  VID  by  correlating  indications 
and  warning,  electronic  emissions,  profile,  point  of  origin  or  initial  detection,  air 
tasking  order,  and  electronic  data  received. 

•  Conduct  internal  communications  and  external  communications  with  battlegroup 
commanders  and  aircraft. 

•  Engage  in  self-defense. 
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•  Verify  positive  communications  and  communication  equipment  check  for  departino 
strike'  force  aircraft. 

Results  for  time  and  accuracy  of  reporting  new  tracks  to  the  battlegroup  are  shown  in 
Figures  20.9  and  20.10.  There  was  a  large  decrease  in  performance  variability  from  the 
AEGIS  crews  to  MMWS  versions  BC1  and  EC2.  The  results  are  shown  for  the  first  and 
second  half  of  the  scenario  test  period,  with  the  first  half  being  the  lower  workload  period. 
Note  that  performance  variance  decreases  for  the  Basic  and  Enhanced  MMWS  design  in 
both  the  low  and  high  workload  periods.  The  low,  medium,  and  high  ranked  tracks  within 
25  critical  scenario  events  are  shown,  with  indication  that  MMWS  teams  were  better  able 
to  balance  their  workload  among  the  types  of  scenario  events. 

The  “overall”  score  shows  a  summary  of  all  scenario  periods  with  a  similar  decrease  in 
variance.  The  high  variance  of  results  with  legacy  system  teams  requires  a  large  number  of 
subjects  (greater  than  20  teams  calculated)  to  allow  for  inferential  statistics.  The  low 
variance  of  performance  with  MMWS  indicates  that  an  increased  homogeneity  of  response 
may  be  possibly  a  result  of  the  design  features  guiding  user  information  processing 
through  the  task  cycle. 

Figure  20.10  indicates  that  fewer  MMWS  users  missed  performing  the  report  tasks, 
with  only  one  report  missed  by  the  two  MMWS  EC  teams  tested.  There  were  fewer  missed 
tasks  in  the  first  and  second  scenario  periods,  with  reduced  performance  variance.  The 
legacy  system  relies  on  poorly  coded  graphic  displays  with  a  burden  on  human  visual 
search  tasking  to  locate  and  define  task  opportunities. 

The  MMWS  provides  enhanced  visual  cues  for  task  initiation  yielding  fewer  missed 
task  opportunities.  Table  20.11  shows  SA  results  for  a  few  of  the  critical  scenario  events. 
Track  number  132  was  a  critical  event  where  evidence  was  built  over  several  minutes  that 
the  track  might  have  hostile  intentions  toward  the  firiendly  forces.  The  track  eventually 
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Figure  20.10  Averaged  number  of  missed  new  track  reports. 


attacks  friendly  forces.  Note  that  all  the  MMWS  teams  followed  the  information  changes 
about  the  track  represented  by  kinematic  cues  (course,  speed,  altitude,  position)  and 
exhibited  markedly  improved  SA  as  evidenced  by  their  preparations  in  issuing  queries  or 
warnings  leading  up  to  the  time  of  attack.  In  comparison,  most  of  the  AEGIS  teams  using 
the  legacy  equipment  missed  key  kinematic  events,  and  few  teams  issued  queries  or 
warnings  and  responded  with  last  second  engagement  responses  after  the  attack.  Thus,  the 
engagement  outcome  may  be  successful  with  legacy  systems,  but  the  risk  is  higher  due  to 
shortened  reaction  times  with  lower  SA.  Figures  20.9  and  20. 1 0  represent  a  small  subset  of 
data  collected,  and  further  testing  is  required  to  replicate  results  with  larger  sample  sizes. 
The  team  testing  results  correlated  very  well  with  the  speed  and  accuracy  results  obtained 
with  the  same  tasks  and  scenario  with  individual  operators  during  usability  testing. 

Workload  was  measured  by  ratings  of  subject  experts  who  observed  the  crew  members 
and  by  crew  members  themselves  during  scenario  breaks.  Figure  20. 1 1  presents  the  results 
of  the  expert  raters.  Although  the  raters  were  not  condition  blind,  considerable  time  passed 
between  the  legacy  system  data  collection  and  MMWS  collections  (one  year).  Results 


TABLE  20.11  Summary  of  AEGIS  and  MMWS  Responses  to  Critical  Track  Number  TN 132 


Kinematics  Detected  Query/Wamings  Issued 


Engage  Antiship  Missile 
(ASM)  after  attacked 
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Figure  20.11  Subject  expert  ratings  of  workload  (1  =  low,  7  =  high)  over  entire  scenario  period  for 
MMWS  and  ship  board  systems. 

indicate  that  despite  the  smaller  teams  used  with  MMWS,  the  crews  were  not  overloaded  in 
comparison  to  the  larger  crews  using  the  legacy  system. 


20.8.2  Training  Results 

Training  requirements  for  ship  crews  included  knowledge  and  skills  applied  across  several 
task  domains:  (1)  warfighting  and  mission,  (2)  individual  responsibility  and  team  role,  (3) 
system  Command  and  Control  (C2),  (4)  verbal  communications,  and  (5)  work  strategy, 
planning,  and  prioritization.  Subjects  used  in  team  testing  were  experts  in  the  mission 
domain  and  required  no  training  in  mission  tasks.  They  were  skilled  in  communications 
methods  and  vocabulary  used  today.  Training  was  required  in  system  C2.  The  watchstation 
training  required  a  minimum  of  1  to  2  hours  for  simple  usability  studies  and  tasks. 
Approximately  6  to  8  hours  of  training  were  required  for  full  team  testing.  Teams  intact 
from  ships  had  previous  experience  of  working  together  as  a  unit.  Teams  composed  of 
training  personnel  or  instructors  were  familiar  with  individual  tasks  but  not  as  working 
together  as  a  unit.  ’  . ' 

Both  teams  performed  well  with  no  detected  difference  in  results.  Results  indicated  that 
despite  being  challenged  by  new  symbols,  graphics,  operating  procedures,  and  display 
formats,  that  the  crews  using  MMWS  performed  as. well  or  better  than  the  larger  intact 
shipboard  teams.  The  TCD  plays  an  important  role  in  facilitating  training  by  providing  a 
design  focus  on  simple  procedures  across  many  tasks.  Most  MMWS  tasks  could  be 
performed  using  identical  procedural  steps,  allowing  for  simple  procedural  knowledge 
training  that  could  be  extrapolated  across  many  work  activities.  Personnel  commented 
following  training  that  the  watchstation  and  associated  displays  and  tasks  were  easy  to 
learn  and  could  condense  the  longer  training  courses  of  today’s  workstations  into  a  shorter 
time  period. 
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Evidence  from  performance  studies  supports  the  hypothesis  that  the  MMWS  design  may 
improve  mission  performance  and  reduce  mission  risk.  Training  complexity  and  burden 
are  also  significantly  reduced.  While  there  appears  to  be  a  performance  gain  from  the 
Basic-  to  Enhanced-capability  MMWS,  there  is  still  too  little  data  to  make  firm 
conclusions.  The  TM,  decision  aids,  and  dynamic  RPM  in  the  Enhanced  MMWS  version 
appear  to  reduce  performance  variance  and  possibly  improve  decision  reaction  time  and 
ff  reduce  missed  tasks.  The  task-centered  approach  focused  the  design  effort  on  critical  tasks 

f  needed  to  complete  a  complex  mission  scenario.  This  approach  directed  the  design  cost 

ff  toward  the  necessary  display  and  control  elements  to  get  the  “core”  work  done. 

The  cost  benefit  of  these  results,  as  well  as  the  potential  for  crew  size  optimization  due 
:lg  to  lower  workload  and  improved  task  execution,  project  a  significant  role  for  the 
application  of  task-centered  human  engineering  in  future  work  environments.  These 
-f  results  apply  across  various  task  domains  in  other  mission  areas  and  in  ship  propulsion 
f.  and  control  systems. 

A  central  design  theme  in  MMWS  was  the  evolution  of  the  human  role  in  many  C2 
|f  tasks  from  being  a  manual  preparation  of  task  products  to  the  supervisor  and  reviewer  of 

j§f  draft  task  products.  The  human  is  better  able  to  allocate  resources  to  planning  and  strategy 

H  tasks  that  are  difficult  for  the  machine,  and  the  machine  off-loads  the  rule-based  tasks  from 

the  human,  with  a  reliable  and  repeatable  result.  The  challenge  then  exists  to  make  these 
|i  machine  assistants  increasingly  flexible  and  pliable  under  a  variety  of  task  conditions  and 
H  demands,  while  keeping  the  human  informed  to  monitor,  supervise,  and  approve  task 
sf;  activities. 


|  20.9.1  HSI  Principles 

Clearly,  the  focus  on  HCD  in  the  MMWS  design  illustrates  an  example  of  principle  2, 
described  in  Chapter  1 .  But  what  of  the  other  principles?  The  context  of  where  MMWS  fits 
in  the  design  process  also  illustrates  the  relevance  of  several  other  HSI  principles.  Certain 
g  principles  apply  more  to  the  early  concept  design  phase  during  research  and  development 
If  (R&D)  whereas  others  are  more  appropriate  during  later  stages  of  design. 

Leadership  (principle  1)  is  critical  to  the  viability  of  any  project  and  program  from 
concept  through  fielding.  For  innovative  R&D  concepts,  leadership  is  necessary  to  see  a 
state  of  design  beyond  what  exists  today.  The  ability  to  sell  this  “vision”  to  leadership  in 
the  procurement  and  funding  allocation  roles  is  critical.  In  the  case  of  MMWS,  navy 
leadership  puts  forth  a  vision  of  reduced  crews  on  ships,  driven  by  cost  and  budgeting 
f  realities,  as  well  as  recruiting  and  personnel  projections.  This  in  turn  led  to  the  requirement 
f  for  improvement  in  human  engineering  and  crew  workload.  The  conceptual  design  phase 
of  MMWS  required  leadership  with  a  sense  of  vision  that  HSI  methods  and  processes 
|f  could  be  improved  relative  to  the  state-of-art  for  today.  Project  leaders  had  to  be  convinced 
If  that  this  goal  was  worthwhile  as  part  of  a  global  crew  reduction  HSI  strategy. 

I  ;  The  MMWS  project  had  an  interesting  and  unplanned  benefit  for  the  source  selection 
process  (principle  3)  and  documentation  integration  (principle  5).  Military  requirements 
policymakers  are  increasing  both  the  content  and  strength  of  verbiage  applied  to  HSI  in 
■1/  Procurement  documents  for  future  systems.  The  recently  released  Land-Attack  Training 
Guidance  document  (Chief  of  Naval  Operations,  2001)  is  a  good  example.  Notably,  it 
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requires  program  executive  offices  and  program  managers  to  plan  and  budget  for  HSI 
support  activities  during  design  and  procurement.  The  document  also  states  that  “System 
operation  and  watchstanding  requirements  may  be  reduced  through . . .  Enhanced  system 
ergonomic  and  Human  Centered  Designs  that  improve  the  performance  and  efficiency  of 
watchstanders,  especially  in  the  areas  of  information  management  and  operator  inter¬ 
faces  . . .  [and]  Use  of  multi-modal  watch  stations  that  permit  task  sharing  and  optimize 
workload  within  the  watch  team.”  The  document  also  specifies  working-level  integrated 
product  teams  (WIPTs)  that  specifically  include  HSI  and  HCD  as  prime  considerations. 
From  the  government  point  of  view,  the  systems  acquisition  documentation  should  include 
greater  emphasis  on  HCD.  From  the  contractors  point  of  view,  contract  awards  should  be 
given  to  those  with  best  HCD  technical  approach. 

HSI  technologies  (principle  7)  are  recognized  to  be  fast  moving  targets  with  commercial 
hardware  advancements  occurring  in  rapid  succession.  An  important  goal  of  HSI,  there¬ 
fore,  must  be  to  provide  guidance  with  regard  to  HCI  architecture.  Systems  that  place  HC1 
functions  in  a  software  layer  as  either  independent  or  plug-in  components  allow  for  further 
upgrades  and  adaptation  as  technology  quickly  evolves.  The  concept  of  TCD  fits  the  plug- 
and-play  architecture  very  well  as  task  components  are  upgraded  and  added  through  an 
evolutionary  approach.  The  software  design  process  also  benefits  from  the  testing  and 
debugging  afforded  by  a  modular  approach  to  architecture. 

Testing  and  performance  evaluation  (principle  8)  is  a  critical  part  of  the  design  process. 
The  process  of  evolutionary  design  and  usability  testing  differs  from  the  more  conven¬ 
tional  hierarchical  linear  design  method  that  includes  user  testing  at  the  end  of  the  design 
process.  With  iterative  design,  risk  is  mitigated  by  usability  testing  starting  with  early 
conceptual  walkthroughs  on  paper  or  by  creating  low-fidelity  simulations  in  general- 
purpose  presentation  tools  such  as  Microsoft  PowerPoint  before  any  code  is  written  and 
while  requirements  are  in  formation.  While  the  team  performance  tests  were  useful  in  the 
MMWS  design  process,  the  numerous  usability  tests  through  2  years  of  multiple  software 
versions  held  the  most  value  for  risk  reduction.  Design  ideas  were  very  much  changed  or 
discarded  that  had  looked  good  on  paper  but  failed  due  to  a  combination  of  dynamic  task 
demands  and  lower  than  expected  utility  with  operators.  Programs  that  delay  user  testing 
and  hands-on  interaction  until  later  stages  of  design  incur  unnecessary  risk  with  respect  to 


user  performance  and  acceptance. 

The  use  of  highly  qualified  human  factors  practitioners  (principle  9)  contributed 
strongly  to  the  MMWS  design  process.  The  design  requirements  were  stated  and  held  as 
design  goals  by  a  qualified  Ph.D.  human  factors  professional.  There  were  occasions  where 
the  project  team  considered  a  design  path  directed  toward  a  solution  that  was  expedient  for 
software  risk  or  acceptance  of  a  commercial  product  solution  that  did  not  appear  to  support 
human  performance  in  a  desirable  manner.  A  qualified  professional  can  screen  the  design 
options  and  select  options  based  on  HCD  goals  and  performance  improvement.  Many  HSI 
aspects  of  the  design  process  are  invisible  to  the  nonqualified  engineer  who  might  be 
placed  in  charge  of  HSI  by  program  management.  One  of  the  most  difficult  issues  in  using 
checklists  or  guidance  information  is  the  comparison  of  the  task  conditions  represented  in 
the  guidelines  to  the  task  conditions  in  the  current  problem.  The  designer  must  recognize 
whether  task  differences  are  meaningful  and  what  aspects  of  human  performance  are 
affected  by  these  differences.  Another  important  facet  of  professional  support  is  the 
evolving  literature  and  technologies  surrounding  the  HCI.  This  fast-paced  evolution 
requires  dedicated  professionals  to  keep  abreast  of  changes  relevant  to  any  engineering 


project. 
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20.9.2  Navy  HSI  Capability  Maturity 

In  general,  it  can  be  said  that  within  the  navy,  the  underlying  government  procurement 
organization  structure  is  trying  to  enhance  recognition  of  HSI  considerations  during 
design.  In  most  program  execution  offices,  however,  the  HSI  responsibilities  still  are 
buried  at  a  level  far  down  in  the  organization  hierarchy  and  typically  as  a  collateral  duty. 
The  procurement  officer  may  be  in  the  hardware  display  or  information  systems 
component  of  the  project.  The  prevalent  conception  among  the  engineering  community 
is  that  the  HSI  issues  revolve  around  display  formats  or  use  of  color  formatting  at  a 
superficial  design  level.  Human  factors  professionals  are  not  consulted  during  the  system 
requirements  definition  phases  or  other  early  design  processes. 

Moreover,  even  though  there  is  increased  recognition  that  usability  is  a  system  design 
requirement  having  great  importance,  there  is  little  R&D  or  development  funding  to  follow 
through  in  improving  HSI  nor  are  there  penalties  for  HSI  ignorance.  Design  problems  are 
often  passed  along  as  issues  that  the  training  community  must  address  when  the  system  is 
fielded.  The  Department  of  Defense  (DoD)  engineering  community  still  attacks  the  myriad 
of  problems  in  complex  information  and  C2  systems  from  a  network  and  hardware 
architecture  perspective,  with  HSI  narrowly  seen  as  a  problem  of  maintaining  consistency 
in  the  graphics  user  interface  (GUI).  Performance  goals  or  requirements  are  not  quantified, 
leaving  no  specific  human  performance  requirements  with  which  to  test  design  success  or 
failure.  Thus,  currently,  the  many  components  of  HSI  do  not  drive  broader  design 
solutions,  and  the  main  tenants  of  task  coverage  and  dynamic  task  life-cycle  support 
discussed  in  this  chapter  are  not  widely  known  or  considered. 

However,  design  success  stories  such  as  MMWS  should  increase  the  education  and 
awareness  level  of  management,  while  increasing  the  awareness  of  the  user  community 
that  improved  HSI  is  feasible.  If  user-centered  design  processes  and  successful  results 
increase  the  number  of  visible  system  successes,  particularly  with  respect  to  system  life- 
cycle  costs,  the  prospects  for  improved  HSI  during  the  design  process  will  increase. 


NOTE 

1.  MMWS  was  conceived  by  the  Space  &  Naval  Warfare  Systems  Center,  San  Diego  and  supported 
under  the  DD21/ONR  Manning  Affordability  Program  executed  through  the  Office  of  Navy 
Research,  Arlington,  Va. 


REFERENCES 

Allard,  K.  (1996).  Command,  Control  and  the  Common  Defense ,  rev.  ed.  Chapter  6  “Tactical 
Command  and  Control  of  American  Armed  Forces  Problems  of  Modernization,”  Section  “Some 
Conceptual  Models  of  Command  and  Control”  Washington,  DC:  National  Defense  University,  pp 
153-160. 

Bush,  C.  T.,  Bost,  J.  R.,  Hamburger,  P.  S.,  and  Malone,  T.  B.  (1999,  April  14).  Optimizing  Manning 
on  DD21.  In  Association  of  Scientist  and  Engineers  Proceedings.  Arlington,  VA. 

Chief  of  Naval  Operations.  (2001,  January  26).  Surface  Combatant  Land  Attack  Warfare  Training 
Requirements  Document.  Washington,  DC:  CNO  Land  Attack  Capstone  Organization. 


792  HUMAN-CENTERED  SHIPBOARD  SYSTEMS  AND  OPERATIONS 

Endsley,  M.  R.,  and  Garland,  D.  I.  (2000  July  31-Aug  4).  Pilot  Situation  Awareness  Training  in 
General  Aviation.  In  Proceedings  of  the  International  Ergonomics  Society /Human  Factors  & 
Ergonomics  Society  2000  Congress  pp.  2-357  to  2-359,  San  Diego,  CA:  HFES. 

Fowler,  F.  D.  (1980)  Air  Traffic  Control  Problems:  A  Pilot’s  View.  Human  Factors,  22(6),  645-653 

Freeman,  J.,  and  Cohen,  M.  A.  (1998).  Critical  Decision  Analysis  of  Aspects  of  Naval  Anti-Air 
Warfare,  Tech  Report  98-2.  Arlington,  VA:  Cognitive  Technologies. 

Freeman,  J.  T.,  Cohen,  M.  S.,  Serfaty,  D.,  Thompson,  B.,  and  Bresnick,  T.  (1997).  Training  in 
Information  Management  for  Army  Brigade  and  Battalion  Staff:  Methods  and  Preliminary 
Findings,  Technical  Report  1073.  Ft.  Knox,  KY:  U.S.  Army  Research  Institute  for  the  Behavioral 
and  Social  Sciences  Armored  Forces  Research  Unit. 

Hildebrand,  G.  (1999,  November  24).  Project  Memorandum.  Track  Prioritization  by  Task. 
pp  1-2. 

Hildebrand,  G.  (2000,  September  26).  Personal  correspondence,  pp  1-2. 

Jones,  D.,  and  Endsley,  M.  (2000).  Overcoming  Representational  Errors  in  Complex  Environments. 
Human  Factors,  42(3),  367-378. 

Kellmeyer,  D.,  and  Osga,  G.  (2000,  July  31-Aug  4).  Usability  Testing  and  Analysis  of  Advanced 
Multimodal  Watchstation  Functions.  In  Proceedings  of  the  International  Ergonomics  Society/ 
Human  Factors  tfe  Ergonomics  Society  2000  Congress,  San  Diego,  CA:  HFES. 

Kelly,  R.  T.,  Morrison,  J.  G.,  &  Hutchins,  S.  G.  (1996  September  22-26).  Impact  of  Naturalistic 
Decision  Support  on  Tactical  Situation  Awareness.  Proceedings  of  the  40th  Human  Factors  and 
Ergonomics  Society  Annual  Meeting,  Philadelphia,  PA:  HFES. 

Klein,  G.  (1993).  A  Recognition-Primed  Decision  (RPD)  Model  of  Rapid  Decision  Making.  In 
G.  A.  Klein,  J.  Orasanu,  R.  Calderwood,  and  C.  E.  Zsambok  (Eds.),  Decision  Making  in  Action: 
Models  and  Methods,  Norwood,  NJ:  Ablex. 

MacMillan,  I,  Serfaty,  D.,  Cohen,  M.,  Freeman  F.,  Klein,  G.,  and  Thordsen,  M.  (1997).  Advanced 
Multimodal  Watchstation  Quick  Look  Critical  Decisions  in  the  AMMWS  Air  Dominance 
Scenario.  Unpublished  Technical  Report.  Prepared  by  Decision  Spectrum  Group  for  NSWC- 
DD  CSACT  Laboratory,  Naval  Surface  Warfare  Center,  Dahlgren,  VA. 

Manes,  D.  I.,  St.  John,  M.,  and  Smith,  C.  A.  P.  (1999).  Response  Planner  &  Manager:  Human 
Computer  Interface  Issues  and  Display  Design.  Unpublished  Technical  Report.  Pacific  Science  & 
Engineering  Group,  San  Diego,  CA. 

McFarlane,  D.  C.  (1997).  Interruption  of  People  in  Human-Computer  Interaction:  A  General 
Unifying  Definition  of  Human  Interruption  and  Taxonomy,  .Report  NRL/FR/5510-97-9870, 
Washington,  DC:  Naval  Research  Laboratory. 

Meister,  D.  (1985).  Behavioral  Foundations  of  System  Development,  2nd  ed.  Malabar,  FL:  Robert  E. 
Drieger. 

Morrison,  J.  G.,  Kelly,  R.  T.,  Moore,  R.  A.,  and  Hutchins,  S.  G.  (1997,  April  14—17).  Tactical 
Decision  Making  Under  Stress  (TADMUS) — Decision  Support  System.  Paper  presented  at  the 
IRIS  National  Symposium  on  Sensor  and  Data  Fusion,  MIT  Lincoln  Laboratory,  Lexington,  MA. 

Naval  Sea  Systems  Command  (NAVSEA).  (1996).  SC-21  Concept  of  Operations  (CONOPs)  DD  21 
Ship  Requirements,  Draft  Rev.  (3)  12/17/96.  Washington,  DC:  NAVSEA. 

Naval  Sea  Systems  Command  (NAVSEA).  (1997).  Operational  Requirements  Document  (ORD)for 
Land  Attack  Destroyer  DD  21,  Document  479-86-97  (Unclass  version).  Washington,  DC: 
NAVSEA. 

Naval  Surface  Warfare  Center  (NSWC).  (1997).  SC-21  Combat  Information  Center  Top — Down 
Function  Analysis,  Technical  Report  (unnumbered).  Dahlgren,  VA:  NSWC,  Basic  Commerce  & 
Industries,  Planning  Consultants,  Carlow  International. 


REFERENCES  793 


Naval  Surface  Warfare  Center  (NSWC).  (1998).  S&T Mission  Function  Analysis.  Technical  Report 
(unnumbered).  Dahlgren,  VA:  NSWC,  Basic  Commerce  &  Industries,  Planning  Consultants, 
Carlow  International. 

Neerincx,  M.  A.  (1999)  Optimising  Cognitive  Task  Load  in  Naval  Ship  Control  Centres  Proceedings 
of  the  Twelvth  Ship  Control  Systems  Symposium,  19-21  October,  The  Hague,  Netherlands. 

Obermayer,  R.  W.  (1998).  Human  Computer  Interaction  Design  Guidelines  for  an  Alert  Warning 
System  and  Attention  Allocation  System  of  the  Multi-Modal  Watchstation.  Unpublished 
Technical  Report.  Pacific  Science  and  Engineering  Group,  San  Diego,  CA. 

Osga,  G.  A.  (1989).  Measurement,  Modeling  and  Analysis  of  Human  Performance  with  Combat 
Information  Center  Consoles,  Technical  Document  1465.  San  Diego;  CA:  Naval  Ocean  Systems 
Center. 

Osga,  G.  (1991).  Using  Enlarged  Target  Area  and  Constant  Visual  Feedback  to  Aid  Cursor  Pointing 
Tasks.  In  Proceedings  of  the  35th  Human  Factors  and  Ergonomics  Society  Annual  Meeting  (pp. 
369-373).  San  Francisco,  CA:  HFES 

Osga,  G.  (1995,  February).  Combat  Information  Center  Human-Computer  Interface  Design  Studies, 
Technical  Document  2822.  San  Diego,  CA:  Naval  Command  Control  and  Ocean  Surveillance 
Center  RDT&E  Division. 

Osga,  G.  (1997,  February).  Task-Centered  Design.  Briefing  presented  at  the  Second  Multimodal 
Watchstation  Architecture  Working  Group,  San  Diego  CA:  Naval  Ocean  Systems  Center. 

Osga,  G.  (2001).  Human-System  Integration  Review  Distributed  Network  Control  System  for  YP  679, 
Technical  Note  1815.  San  Diego,  CA:  Space  &  Naval  Warfare  Systems  Center. 

Osga,  G.,  Van  Orden,  K.,  Campbell,  N.,  Kellmeyer,  D.,  and  Lulue,  D.  (2002a).  Design  and 
Evaluation  of  Warfighter  Task  Support  Methods  in  a  Multi-Modal  Watchstation,  Technical 
Report  1874.  San  Diego,  CA:  Space  &  Naval  Warfare  Command  Systems  Center. 

Osga,  G.,  Van  Orden,  K.,  Campbell,  N.,  Kellmeyer,  D.,  and  Lulue,  D.  (2002b).  Task  Description 
Documents  for  Air  Defense  Warfare  Design  Support  in  the  Multimodal  Watchstation,  Technical 
Note  3130.  San  Diego,  CA:  Space  &  Naval  Warfare  Systems  Center. 

Rasmussen,  J.  (1986).  Information  Processing  and  Human-Machine  Interaction:  An  Approach  to 
Cognitive  Engineering.  Amsterdam:  Elsevier. 

St.  John,  M.,  Manes,  D.  I.,  Moore,  R.  A.,  and  Smith,  C.  A.  P.  (1999).  Development  of  a  Naval  Air 
Warfare  Decision  Support  Interface  Using  Rapid  Prototyping  Techniques.  In  Proceedings  of  the 
1999  Command  and  Control  Research  and  Technology  Symposium.  Washington,  DC:  National 
Defense  University. 

St.  John,  M.,  and  Osga,  G.  (1999,  October).  Supervision  of  Concurrent  Tasks  Using  a  Dynamic  Task 
Status  Display.  In  Proceedings  of  the  43rd  Human  Factors  &  Ergonomics  Society  Annual 
Meeting  (pp.  168-172),  Houston,  TX:  HFES. 

Wickens,  C.  D.  (1987).  Information  Processing,  Decision-Making,  and  Cognition.  In  G.  Salvendy 
(Ed.),  Handbook  of  Human  Factors,  1st  ed.  (p.  81).  New  York:  Wiley. 


